Episode Summary
We build software. Great, so what is the actual cost of software development? There are plenty of reasons you may want to build custom software, but you probably have some questions about how much money you’re going to have to throw in to get exactly what you want. We go through how we estimate software costs and what the final numbers will look like.
Visit cityinnovations.com/ask-an-innovator for some helpful links and the full transcript.
If you have questions about what an app may cost or if you have a concept you’re looking to get some help with – schedule a free consultation with us!
We’ve written a few things about Software Development
How to Contract the Right Software Development Company
Learn more about Agile Software Development
Learn more about Lean Development
We reference this podcast a lot in this episode
Timestamps
How do you give estimations for software – 00:32
What does the estimation process look like? – 02:32
How do changes to scope affect the cost? – 07:22
How do we stay within budget – 09:41
How do I ensure my investment – 11:19
Isn’t there a way to build software cheaper? – 14:32
What questions should a customer ask about cost? – 15:46
What costs will I run into after the project is completed?– 18:40
Give me a dollar amount – 21:41
Full Podcast Transcript
Erin Srebinski: [00:00:00] Hi and welcome to Ask an Innovator. We’re here to talk about innovation in the software development space. Sometimes us, and sometimes others. This podcast is brought to you by City Innovation Labs.
Hey, this is Erin and Josh from City Innovation Labs. We’re here today to talk about software development costs. I have no idea what I’m doing. So Josh is going to kind of walk me through what it costs. Here we go. So Josh, how do we do estimations for software development? What does that entail? How do you get there? What do you give the customer when you’re finished?
How do you give Estimations for Software?
Josh Barker: [00:00:32] Yeah, it’s a great set of loaded questions you’re asking right now. usually we’ll get that right away from customers that say what is software costs. And so a lot of people have preconceived notions that come in and if you’re a startup bright eyed, bushy tailed, you’re a young person saying I’ve got an idea and they come to the table. And I think that way discouraged a little bit because software is expensive.
Being frank, software is a very expensive endeavor. It’s not a $500 endeavor, add a few zeros and you’re looking at that sort of endeavor. That’s where we help customers understand the why’s behind software costing so much. It definitely is a loaded subject that has so many different avenues of helping customers discover how much does this cost
The analogy I like to use a lot is actually the one of building a house. You can imagine if you go out and you build a house, you don’t go out and build a house. You don’t go out and ask a builder, “How much does it cost to build a house?” Like, that’s just like, right.
It’s like, that’s what you’re asking. How much does it go? The builder’s going to ask back, well, does it have a basement? Does it have two double stall garage? Does it have, two-story like, why give me details? And that’s what we are talking about? Is it a shed? You know, like if it’s a shed, it’s a lot less, you know?
That’s exactly the type of tension that we deal with when people ask, well, how much does software cost? Generally speaking, if they want early kind of numbers, I’ll give them ranges of costs that says it could cost anywhere between here to here for this sort of thing. But, it’s really difficult unless you start to really dive in with the customer about what is it you’re exactly trying to build. Software is a very custom thing. And so when we’re building it, just like a house just like spec houses, there is such a thing as we could set up open-source software that we kind of have some ranges of how much that would cost better dialed in, but a lot of it is just going to be completely custom.
What does the estimation process look like?
Erin Srebinski: [00:02:32] Okay. When we’re working through that and trying to give an estimation and tell them what it is, what process do we go through to get a better picture of what that actually means?
Josh Barker: [00:02:43] That’s good. So what we do is we first we have an initial conversation with customers and we say, “What is it, give us the high-level executive summary of what you’re trying to accomplish.
Generally speaking, that’s a 30-minute conversation. Usually in that meeting, we schedule a lightweight product strategy workshop. We offer a full strategy workshop and an innovation workshop, two different types of workshops, but we offer a very lightweight workshop to those types of customers that we say, “Hey, what we really need is about an hour or two of your time,” to guide them through some exercises to understand what needs to be built.
Right? So orders of magnitude, what are we talking about? In that workshop, we do three different exercises. We do persona creation and mapping. I group that under one exercise, we’re very human-centered in our software development. You know, we, Erin and I talked about lean startup, listen to that podcast on how we do software differently, but we effectively start with the market and the end-user.
And so who is that? What are their core needs, their fears, their wants their desires, how are they going to use it? And so we create these personas and even put names to them. You know, we’re creating software for Bill, but we’re also, secondarily, creating it for Mary and Joe. And so we create this map and we map out the customer and then that helps us inform, as we’re talking about.
The second thing we do is we go through a journey mapping session. So these are all design thinking exercises of helping our customers understand kind of the process of what they’re asking to build. And so we go through and we map out if there’s a current process, some manual process, we map out the current journey and then identify friction points.
And if there is a future, you know, we’re taught, it was a future process, right? What would it be with the app or the thing we’re building? We map that out. We mapped that all out and we can kind of visually see it. And then the last thing we do, each one of these kind of lead to another, is story mapping.
Story mapping is the process of kind of mapping out. We map out the high level, what I would call Epic level features, the large buckets. So for example, we know that the app you’re asking for needs a login, that needs this other thing. We map out a lot of those different large bucket features and then we even move them and dial them in too. We talked about it in the lean startup podcast: the skateboard, scooter, motorcycle, car, and we divide them into these different phases.
Then we can come to, this is what our MVP would be, delivering a skateboard to the marketplace. Generally, that’s the process. We have a D4 Innovation Model and what that model is, is it’s a very structured way of how we build. The first step is we try and map to the cone of uncertainty. So that’s something that you could literally Google. It’s not something I came up with it’s a project management concept.
The amount of time that you’re estimating what are the ranges? So estimation versus variability and the estimation ranges. So earlier on, for example, if someone would come up to me and say, “Hey, I want to build an app. How much is that going to cost?”
Well, I’m going to give you terrible estimates because I have no idea what you’re talking about. Right? The more information I have, it’s a simple cone. The more information should I have, the more conversations I have with you, the more documentation I make, the more prototypes we make, we can narrow that down.
Our D4 Innovation Model maps over that perfectly where we first have a discovery. Sometimes that’s in the form of a workshop. Other times for larger projects, we might need a discovery engagement. Once we have that information that moves into where we’ll interview customers, your customer’s customers. We’ll map everything out in a lot greater detail that allows us then to create a prototype.
We create a prototype and the way I phrase it, using the house analogy like a blueprint for a house, right? You contact an architect and then you’re like, Hey I want a two story with a basement. And so we go through and rapidly prototype much faster than when we build the app.
We rapidly prototype what you’re asking or thing that you want to bring to market. And then after we build that, we’ve got a nice blueprint to know how much development costs will be, which is deliver. That’s the next D4. So you’ve got Discover, Draft, Deliver. And then after that you’ve got Disrupt, which is largely when we do a lot of continuing innovation and adding to the product. those are the high levels of how we would go about the estimation process.
How do changes to scope effect the cost of software development?
Erin Srebinski: [00:07:10] I’m kind of putting my customer shoes on here and that sounds great. So you’re going to give me a large range, right? I’m going to get a range of what it might cost depending on what this prototype looks like. And if I want to make changes, when do I do that? And do I make it in the prototyping phase? Do I make it in development? Because I imagine that could change the cost depending on how we do that. So can you go into that a little bit?
Josh Barker: [00:07:30] Yeah, absolutely. Generally speaking, our cost model is we’ll give you ranges, but we’ll also give an estimated spend. We’ll say this is what we recommend for what you’re suggesting you spend. That model is a fixed-cost, variable scope. What we mean by that is it allows some flexibility in both directions too. Usually we’ll have it be very hands-on in the prototyping stage.
Let’s say in the prototyping stage, we gave you an estimate of how much that will cost ahead of time. We’ve got a budget, right? And then in that process, we learn new things because we get feedback from customers. This is what happens. All the time. Technically, if it doesn’t happen, there’s a little bit of nervousness of like, “Oh man, no one is really engaged in this process.”
What’s wrong. Right. We try and bake that into the process of knowing it’s an iterative process of getting in front of customers. They’re going to tweak it a little bit. So in our estimate, we do try and include that in addition, because it’s fixed cost, variable scope. Oftentimes whether it’s prototyping or software development, we work with the customer to prioritize what is the most important thing in what we’re delivering.
We focus on those things most important, as well as the highest risk items. And we prioritize those towards the top. And so we say we have to nail these things. Then we kind of get into this after the top four, five, six, seven, 10 things you get into this. Well, these are in the “nice to have” category.
And so because of that fixed cost variable scope, if we have enough time, we can add those nice to haves, but generally we really try and help the customer or identify the cutoff of what I need and we estimate that way.
How do we stay within budget?
Erin Srebinski: [00:09:14] Okay. Yeah, that makes sense. So when we’re working with a customer, I imagine they sometimes have a tight budget, so how do we ensure that we stay within that budget?
I know you kind of just went over that, but how do you prioritize features? Do you do that with the customer or do you do it internally? How does that work?
Josh Barker: [00:09:30] Oh, great question. So oftentimes, especially in the prototyping phase where costs can go haywire with any custom software development company is really when you start the actual engineering process. You start coding and oftentimes you run into unforeseen things. Or if you get it in the hands of users and you get feedback. So that thing we planned for, yeah, no one wants that anymore. Okay. Well, great. Well, we can chop that. That works in the customer’s favor to reduce costs, but what about the other direction?
What if we get it in the hands of users and they say you’re missing a huge component of that, right? That’s where the customer’s involved. Typically what we’ll say is because we’re focused on an MVP to market as fast as possible, we’ll try and put ourselves in their shoes and help them with the compromised process of like, “Hey, here’s some features we said were important. Here’s one that the customer came back and said that we have to do.”
We can look at this list and exchange, right, and say, well, instead of doing this one, let’s do this. What do you think of doing this one, instead? It’s a very collaborative process. One of the things that I sometimes customers come back and they’re like, “Well, I don’t want to do that.”
You committed to doing this whole thing. And what people have to understand is with the house analogy is the fact that you’re building the house, not for yourself, but other people.
Right? So you’re inviting them into the process. And so if you get an estimate and a quote from some architect to say, here’s how much it’ll cost. Builder’s like, “Yup, this is how much it’s going to cost.” You start to iterate as you’re developing it and you realize that the people that live there don’t want some of the stuff that you suggested to put in there. Cost obviously has to change.
You have to play this game of, well, we can keep this fixed cost as long as we can. You know you wanted three bathrooms, as long as we knock off one of the bathrooms we can get the rest of it.
How do I ensure my investment?
Erin Srebinski: [00:11:19] Got it. Yeah. That seems to make sense, you wouldn’t buy a house and not want to pick the cabinets. If you’re building it, you want to pick all those things.
I imagine picking features and being part of that process is really important to the customer. And that helps you kind of gauge cost as you go along because you find out what’s important and what matters to them and how they, we really want to do this. But to poke holes in this, I’m going to spend all this money, how do I know that it’s worth it? How do I know that I’m going to get something that works for me? How do you ensure that when we’re building software and when we’re spending all this money?
Josh Barker: [00:11:52] This is the Holy grail of questions. Isn’t it? It’s like Josh, what’s your crystal ball say about my idea. Right? It’s a great question. So what I, what I tell people is this is, this is why City Innovation Labs exists. Most custom software development firms, what will end up happening is they’ll build the thing that you asked for, which is not a bad thing if you really want that thing. But if you don’t know the market and there’s some risks, which sounds like Erin, loaded in this question, which I’ve heard from customers is there is some uncertainty, there’s some risk involved. How do I know I’m going to get the return and how do I know it’s going be used? This is why in our process, we have baked in taking small bets. Taking small risks and testing.
So we talked about in the lean startup episode of this, about MVT, right? Minimum viable tests. We talked about MVP, and then we talked about MMP. So Minimum Marketable Products. When we build software, we don’t go for the minimum marketable product.
First, we help them build, really educate them on what MVTs would be useful, and help them run the MVTs. when they come to us, we help them say, okay, Here’s what we can do to build an MVP and we’ll build a rapid prototype very, very quickly. Usually, that’s a lot lower cost, like I was mentioning before, and faster than building the actual software. We encourage them, take it to the market, get feedback, and let’s iterate on it together. And the nice thing is, is you can also use these prototypes that we build for. If you have an investor or you need to sell this up in your company, we have this as a piece that you can get buy-in, or we’ve even seen it where customers get pre signups, which is almost the best-case scenario.
Get some pre-sign ups. Put together a landing page. Sell this thing. Listen to the lean startup episode. We talked about Dropbox. Yeah. Effectively you can get pre-sign ups and have that even generating revenue before we even touch a line of code.
Generally, that’s a much smaller spend creating a prototype. And then once we start that process and we can get some level of confidence, that’s why this is so important that you bring it to users and you even see if you can get pre-sign ups, then we can start to talk about what’s important, what’s not important, what’s the feedback? We can iterate on that and start developing a skateboard version of this, to release to the market. And by that time you’ve got market validation, you’ve maybe even had some pre signups. We’re doing it incrementally, versus if you go to another firm, they’re gonna want to do a big bang. Instead of spending all this tremendous quarter million dollar plus funds, you’re spending a very small fraction of that first testing the market and seeing if there’s actual traction before investing more dollars.
Can’t I do it cheaper than this?
Erin Srebinski: [00:14:32] That makes total sense. When I’m thinking about this, and I’m shopping around. There’s things where you can build your own app, right? Where you could build it for cheap and you could do that. So what’s the benefit of using someone like CIL or a software development company versus doing it that way? Besides the intense learning curve that I imagine exists?
Josh Barker: [00:14:50] What you just articulated of, why wouldn’t you build one with a low code, no code solution that already exists in the market? I think that’s a great idea. The first thing you should do is do that. Like I’m being straight with everyone that’s listening. Do that first and then after you get feedback and you iterate in the marketplace, that’s the MVT. That’s a minimum viable test, a great way to test your market. Have us help you test the real thing. And then say, now that you’ve got interest in the value. Let’s go and see if we can make this thing really awesome and do a custom build.
Just like Groupon’s story, they use WordPress, they didn’t go out and build something super custom. What’s hilarious is I almost un-sell people as my first objective to us to go, have you done this low code? No code? And I preach from the mountain tops, like do this first. And if they say I’ve already done all that, here are the results, it’s like, great, let’s go to the next step. So oftentimes I encourage that.
What questions should a customer ask about cost?
Erin Srebinski: [00:15:46] Okay. That’s great. when they are shopping, they come to you and they’re ready. What kind of questions should a customer ask to really get feedback about why it costs what it does? Are there good questions that they should come into the conversation with?
Josh Barker: [00:15:56] Yeah. That’s a great question too. I would say if you’re going to engage any custom software development firm is, “Help me understand how this is related to a go-to-market strategy.” Right? So, because a go-to-market strategy, meaning we just talked about getting pre-sign ups and then stepping into finding out where existing traffic is and who you’re going to market to.
And so these are all great questions that I believe makes us a huge differentiator in the marketplace. we don’t just go build it and then say good luck, have fun, see you later. Thanks for the hundred thousand plus dollars. We don’t do that. We literally put ourselves in the shoes of our customers and say, here’s what I would do.
I’d do a Kickstarter campaign. Here’s some options let’s brainstorm together. And we have this brainstorming process where it’s very collaborative, where we’ll come out and that person should ask us what is the go to market strategy? Like how would I go about doing that?
Josh Barker: [00:16:54] If they’re not willing to have a conversation about that, that in my mind is a red flag if you’re talking about costs. You mentioned a couple of questions ago, Erin, you want to know that you will get a return and you’re not going to spend a quarter million dollars on something that’s a flop.
Instead, you’re going to want to spend a fraction of that discovering, Hey, this might not be a great thing or discovering a pivot you need to make to make it a great thing. That would probably be the number one question. you can also ask the question of, “Is this a minimum viable product?”
That would be a great question to ask any software development firm. Most software development firms in this industry make their money by upselling and selling larger projects.
Now, I feel actually bad about that and convicted to be like, I don’t want to charge people for something that users probably wouldn’t be using. I would feel bad about that. And so that’s the thing is asking that question too, “Is what we’re creating a minimum viable product?”
How can we make it more minimum viable? How can we trim this down? Ideally, you’d work with a firm that has already done the legwork to pare that down to the value that they can go to market minimally with instead of baking in every single thing they can think of under the sun of like, yeah, let’s use AR VR.
Do you really need that for like a banking app? Like logging into my bank? You know?
Erin Srebinski: [00:18:17] That makes sense. They should know what an MVP is, essentially. Most people know what that is. And if you don’t please listen to our other podcasts, obviously, but they should know what that is. They should know how to make that version for you across the board. Or just certain firms?
Josh Barker: [00:18:31] I would say, across the board. And that would even be a red flag, right. If they’re like, “What’s an MVP?” You’re like, “Oh no!”
What are software development costs I could run into after the project?
Erin Srebinski: [00:18:40] Oh, that’s perfect. Okay. So. We’ve built the project. We’re good. We’re in development. Are there costs after that? Do we run into other things? What if I want to add features at the end? What other ongoing costs could there be afterwards that maybe we didn’t factor in at the beginning?
Josh Barker: [00:18:58] Good question. So, the answer to that is very complicated, but I will sum it up in a very short thing. When you build a software product, if you want to make it successful, there is a cost of ownership for that software product. An ongoing cost of ownership. People that I say this to they’re like, what do you mean, you build it and you’re done? We can just leave. You can do that. I’m not stopping you from doing that. However, here’s some things you should know , I’ll just list off a few. If we’re building a mobile app on iOS, Apple releases a new version of iOS and all of a sudden your app doesn’t work. Well, it’s not the apps fault.
Right? We built it in the right way with the way that Apple asked us to. However, now that there’s a new version with new things in it, we need to tweak some things. That would be a classic case. Another thing is, it’s a fallacy that you’re going to build it, get it in the hands of the users and they’re like, this is perfect. We really are on cloud nine, there’s nothing else we want from this thing, it is amazing. Especially if you’re doing an MVP to market, it’s to get feedback to build the next iteration. Because of that, you’re going to get feedback. The users will use it in unintended ways.
For example we’ve released many an app that when we release it, they’ll say, yes, I love this thing. Then you get it in their hands and they start using it. You realize through the data, no one is using the set of features they said they would use. And then you’re like, why did we even build that? Right. If you put in the right analytics tools, you’ll be able to see what features are used more than others and what features are not used at all. And our user’s even getting confused within the app. We can actually see data in those analytics. And when you do that, you then have this powerful , I don’t want to say crystal ball, but you have this powerful insight right?
Into the mind of the user to where then you can see wow, we do need to make changes because people are getting confused here. They’re using this more than this, and they’re not using these things at all. Then when you even start talking to users, you get more information. When you start building a product you’re in for the long haul, you’re in for a longer period of time to where you’re iterating, you’re building on it.
there is going to be upkeep, even if it’s just what we call lights on, which is that first example of Apple flipping a switch and releasing a new iOS version. That’s going to happen. There’s a significant cost of ownership, even users, as I said, using in unintended ways. If they use it in unintended ways, sometimes the programmers don’t program it right since they’re human and they don’t think of those ways. They end up finding bugs and then we have to fix those. That is all of the different things wrapped up in what might be after you launch. Not even might, has a high likelihood to happen. Yes.
Give me dollar amount – what is the cost of software development?
Erin Srebinski: [00:21:41] When you were talking about that, I was thinking we were talking about early adopters and how they go nuts and say, well, we want all these features. This is how we use it. You take all that information. You’re like, whoa, we need to make this way more robust, we can pare this down. It’s so interesting, one point of view is your narrow focus and then you see all these people and you’re like, I didn’t even think to use it that way, that’s genius. So that makes a lot of sense. So I’m going to ask this really direct question that customers might ask you. Like, give me a ballpark range. What does it really cost? Am I spending $400? $5,000? Am I spending $8 million? What am I going to spend on this software?
Josh Barker: [00:22:18] Again, complicated answer, but I’ll actually give some definitive numbers. If you went to another firm and you were to lay out your vision for the app, they’re going to try and slam that all into one huge, big bang release. Generally speaking, that could be in the millions of dollars, like a very large software project. So mobile, even a web portal component. It could be a very expensive endeavor. So that’s a huge reason why we pare it down to these phases in our D4 innovation model .
And so with the Discover, Draft, Deliver, Disrupt – they each have their own, I would call them ranges that we’ve generated generally seen. So I can give usually when a customer comes to me and says, give me a swag. I usually give these ranges of like, “Hey, this might be a gut check for you. Is this really where you want to put your money?”
Because at this point, I think there’s probably some people listening saying, is this an endeavor that I actually want to even begin to entertain and go down? Generally, that’s why I throw out these numbers. So to remind everyone we’re doing a lot of end-user discovery, doing customer interviews, doing user interviews. If it’s a larger project, generally speaking, we’ll have a separate discovery phase. In that discovery phase, that can be anywhere between $25,000 to $50,000. So it’s expensive, but your goal is to really narrow in on: are you building the right thing?
And so for us, the Discovery and the Draft phases are so important too, to narrow that down, to make sure you are building that right thing. You could go the complete opposite direction and build the completely wrong thing. That’s why it’s so important. The next phase after that is Draft. Other times we crammed the Discover and Draft phases together, depending on how much information we have, how large is the project? Generally speaking, the Draft phase ranges anywhere between 35K up to 60K for a prototype.
That’s in a general sense, we’ve seen it be higher. There are some outliers there because of how large-scale the project is. How many people? That’s also a huge factor because we’re getting iterative feedback. If we need to involve 30 people, it’s going to be a more expensive prototype because we need to get feedback and incorporate feedback from so many people. That’s the prototyping stage. And then when you move into development, it’s about 4-6x of what the prototype would be for an MVP.
If it’s 25,000 for a prototype. I know I said 35, but just for easy numbers, I like easy numbers. It’d be 100K for the app build and it could be up to 150K. We’ve seen lower and we’ve seen higher. The encouragement here would be, if you’re considering, should I build an app or shouldn’t I? We would actually be happy to talk with you on that point. Like I said earlier in this podcast, I have no problem of telling people now’s not the time to build something, now’s the time to run MVTs.
I love talking to people. So I’d be happy to give you some advice to say, “Hey, yes, we can help you do that or, you really need some more information.” We offer workshops to help people think through what could be some Minimum Viable Tests we could run.
Those are the kinds of things we would love to talk with you about. And because software is so custom, while I throw out all those numbers, the best way to do it would be to get in touch, and just say, “Hey, this is what we’re thinking, this is what we want to build.” I’d be happy to have a conversation with you about paring those numbers down and maybe some advice about some next steps.
Erin Srebinski: [00:25:38] I think that’s great. If I had an idea and I talk it through with someone they’re like, well, you’re not even close to being near ready to do this. It’s super helpful. And you have another direction to go. I feel like I know exactly what software costs at this point. Thanks for joining me today and talking about it.
Josh Barker: [00:25:53] Absolutely. Well, thanks for putting me on the spot with a really hard question that I get asked all the time.
Erin Srebinski: [00:25:59] So you got it. All right, bye.
Josh Barker: [00:26:02] See ya.
Erin Srebinski: [00:26:03] Thank you for listening to ask an innovator please visit us at www.cityinnovations.com/askaninnovator for the full transcript and subscribe wherever you listen to podcasts.
