1: How Long Does It Take to Build an On-Demand App?

Tim and Rob take a shot at answering the oldest question in software development: how long does it take to get an app shipped from scratch?

In this episode, you'll learn:

• What exactly is an "on-demand app"?
• The actual time in months that it takes on average to build an on-demand app (spoiler: it's anywhere from 3 to 6 months)
• Steps you can take to speed up a development project before it even begins
• What to do if your project stalls in the middle of development
• Tips for getting your app into the App Store faster

This episode is brought to you by The Jed Mahonis Group, who builds mobile software solutions for the on-demand economy. Learn more at http://jmg.mn.

Recorded October 19, 2017
Edited by Jordan Daoust

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt.

Rob Bentley 0:06
And I'm Rob Bentley. Let's get nerdy.

Tim Bornholdt 0:22
So Constant Variables. Rob, why are we doing this podcast?

Rob Bentley 0:25
Well, first a little bit about us. We started a company called The Jed Mahonis Group about six years ago. And we specialize in building mobile apps.

Tim Bornholdt 0:33
That's right. And specifically, we've been getting into the on demand space, which we'll get into a little bit later. But we've been building apps for a while now. We've got a lot of experience. We've made a lot of mistakes. We've had several successes as well. So we wanted to just share everything we've learned about mobile app development, and hopefully help people that are starting at "I have an idea" and help them bring it all the way to "I'm a multi billionaire."

Rob Bentley 0:55
Yeah, so today, we wanted to talk about how long it would take to build an app, but not all. Just an app, how long will it take to build an on demand app?

Tim Bornholdt 1:03
That's right. So we wanted to go over some items that, you know, kind of impact the timeline for development before code even gets written. Talk about items that'll impact your timeline during app development, and will also give you some action items you can take away to speed up the app development process.

Rob Bentley 1:18
Right. So we'll start with what is an on demand app?

Tim Bornholdt 1:21
Yeah. So real quick, what we mean by an on demand app, think of something like Uber, Domino's, Postmates, Doordash. Apps that take a service or a good that somebody wants right now, and they need to have it at this specific place. And using technology we make that happen.

Rob Bentley 1:37
This applies to a lot of different industries and markets. Obviously, ride sharing is a big one because everyone's heard of Uber. Food delivery is another big one right now. Yes, it's been been delivered for a long time now. But now other restaurants are starting to get into the space as well,

Tim Bornholdt 1:53
Exactly. But not even just those apps. There's a lot of services that could apply to on demand. So you know, even think liquor delivery, there's a lot of startups that are doing, get some beer sent right to your house, there's, we've worked on an app that helps dental agencies get staffed up with hygienists and assistants. PCA agencies help people that need aid to people that will give aid. You know, there's a million dollar ideas you can could draw from here.

Rob Bentley 2:20
Really. So it applies to a lot of industries.

Tim Bornholdt 2:23
But the gist of it is we want to, we're talking about apps that you take any good or service and get into the hands of somebody right when they want it and right where they want it.

Rob Bentley 2:32
Right. Going along with the instant feel, have everyone feels like they should be able to hit a button and get whatever they want, whether it's good or a service.

Tim Bornholdt 2:38
Exactly. So what does it take to build an on demand app? What are the different pieces that you need to make that happen?

Rob Bentley 2:44
Well, really, you have to create two different front ends, one for the supply and one for the demand. And what I mean by that is, you have a group of people who want something to good or the service and you have a group of people who provide it, and then you need a back end to match up those two front ends.

Tim Bornholdt 2:59
So yeah, with a front end, when you're talking about the customer, so you have, you've kind of the customer that's looking to get the good or service. Usually they're requesting that through a mobile app, it can be a website, we've built both, it's pretty common. The service side, though with doing on demand, it's almost always a mobile app, you want to be able to know where your driver is at all times and make sure that they're able to, when they're out driving around, they can get the good or service delivered on demand. They're not tethered to a laptop.

Rob Bentley 3:26
Right to your location too.

Tim Bornholdt 3:27
Exactly. And then to make those two things happen. You have what's called a back end. And that does pretty much everything. You know, we're talking about coordinating the matchmaking so saying, you, Rob, you want the service and I, Tim, I'm providing the service. That's kind of the 101 of what this app needs to do what the backend provides for that. There's also things like handling payments, being able to not only accept payments from you, that wants the good, but also pays me, who provides the service and then takes a little bit off the top for the company who was facilitating that matchmaking.

Rob Bentley 3:59
And just for the people that don't know too the point of this show is to be non technical as we can. So we're going to use the term back end and server kind of interchangeably, it just means the computer that handles the data for your app.

Tim Bornholdt 4:14
Right. I mean, if you're getting into this space, it will make it as non technical as we can. But you'll also need to kind of know some of the lingo, but we'll, we'll break it down where we can. Also, when we're talking about the backend, another component that it will need to do is be able to handle customer service tasks. So not just if somebody has an issue with a service, but also providing refunds, helping your service providers get on boarded into your system, whatever you basically would need to do to get your service providers to provide that service. And then finally, analytics, you got to make sure that you're tracking where things are going, how people are getting into your system, how they're using it, so that you can continue to grow and optimize your service.

And there are some technical components we need to discuss when you're building an on demand app. They're not on the easier side of the spectrum of building mobile apps. You're going to be dealing with implementing push notifications. This means users get notified when their order's received. People that are fulfilling the service get notified that there is an order to fulfill. All that kind of stuff.

Rob Bentley 5:16
Keeping all that data in sync. So as soon as, if they aren't responding to a push notification, if they just opened the app, the data is current. Search, which would apply if you're shopping, like getting food from grocery store, be able to find bananas easily.

Tim Bornholdt 5:31
And also, if we're talking about not just goods, but it could be if you're looking for a specific service if you're building an app that provides on demand. Like if you're talking about doctors, for example, and you're looking for a very specific specialist, and there's five you can choose from, you need to be able to help guide your person to the right direction for that.

Rob Bentley 5:51
Right if you need a brain surgeon right here right now, a pediatrician probably won't be your best.

Tim Bornholdt 5:57
You need an on demand brain surgeon. I guess someday somebody probably will.

Rob Bentley 6:01
I mean, that's where we're going.

Tim Bornholdt 6:02
That's true.

Rob Bentley 6:03
And then also mobile payment support. Almost all of these apps have that feature built into it where the customer can enter their card info and just pay for whatever they want.

Tim Bornholdt 6:13
Yeah. And you need to be able to deal with all the security aspects that come along with that being PCI compliant and making sure that you're not as hackable as everybody else.

Rob Bentley 6:23
Yeah, if you have someone's payment details getting leaked, that's basically the end for you.

Tim Bornholdt 6:27
Yeah, exactly.

Rob Bentley 6:28
And then a very user friendly design. And this is especially important if your app targets a lot of users, people find really creative ways to do things that break the system. So you need to have a great design in place.

Tim Bornholdt 6:39
Yep. Yeah. Is that it for all the technical components?

Rob Bentley 6:42
Well, probably not. Those are some bigger ones that you'll need to be thinking about. And those are definitely they take time and thought to get done right.

Tim Bornholdt 6:50
Right. And that kind of constitutes what we mean by an on demand app. So keeping that in mind, Rob, in your experience, how long does it take really to build an an demand app.

Rob Bentley 7:01
It kind of depends on what you're going for. If you're going for a release, that's as quick as possible, it's very lean. It's called an MVP, or a minimum viable product. And what that means is, it's the least amount of features, your app can have to get the job done. And those usually take about three to six months.

Tim Bornholdt 7:20
Okay. Makes sense.

Rob Bentley 7:21
If you're going for a more feature rich deployment, or launch or whatever, that will be more like a 6 to 12 month timeline.

Tim Bornholdt 7:29
Sure. So really, the quickest you can get this thing out the door realistically would be three months. And that's with a very lean product, something that just really accomplishes one task. Where if you're looking to build an all encompassing system that can do lots of things, you're looking more towards that six, nine, twelve month range, really, depending on on the the specific app that you're building.

Rob Bentley 7:51
Right. It really depends on the requirements, what your app does, who your market is, what they need, and then how much you want it to be able to do at launch.

Tim Bornholdt 7:59
So 3 to 12 months. That's kind of a wide range there. What are some things upfront that we can basically gauge the timeline that we can say it's going to be more like three months or it's going to be more like 12 months? What are some of the factors that will go into dictating that timeline?

Rob Bentley 8:14
A lot of it actually depends on how well defined the idea is from the get go. Or when you come to us anyway. You'll probably have been working on this for a while before you come to us. But the more details we have the clearer path we have to finalized product, the quicker go.

Tim Bornholdt 8:30
Yeah. So really, it's thinking through the app and really, really knowing your product. There's a difference between I want to build an app that delivers brain surgeons on demand versus like knowing exactly step for step what users, like what is the use case going to be? It's going to be somebody just fell on the ground, had a traumatic brain injury. We need somebody here right now that can handle it. And then knowing all those steps that are going to take to get somebody in the door. It's not just having the general idea. It's really thinking through what we in the in the biz call a user story. And having thinking of the user in mind and thinking, I'm going to pull up my phone, I'm going to tap this thing, which is going to do this. And then I'm going to tap this thing, which is going to do that and thinking through every step and making it so that it's the most efficient process possible to get somebody in and out of your app and accomplish the tasks that they need to get done.

Rob Bentley 9:24
Exactly. So if you can think of every user story that you possibly can, think of how they all interact with each other, because there's certain there's different variables involved, the more you have.

Tim Bornholdt 9:35
And thinking through the edge cases with those as well, because you're going to have a path, the critical path that's going to account for 80% of your usage. Typically, you want to make sure that the 20% that are going off the fringes you need to either be comfortable with ignoring that or figuring out how you're going to deal with that and, and help them get through your app and use your service as intended. Another thing that's going to impact the timeline before development is going to be, what software platforms are you targeting. So this will be something like if you're trying to build an iPhone or an Android app, there's multiple ways you can do it. We and the vast majority of software developers are going to argue for building a native solution, especially when you're building an on demand system. But you can use what's called a hybrid solution, which is targeting both iOS and Android and Windows Phone and whoever else. You're building kind of a write once run everywhere type of solution that lets you get out the door faster in theory. Another thing you'll want to account for is which version of iOS and Android you're going to support. Right now, you know, we're on Oreo, and we're on iOS 11. Do you need to support back to iOS four? Probably not. But maybe you'd want to go back to nine, maybe eight depending on your specific cases and needs. So just keeping those things in mind.

Rob Bentley 10:56
Also, once you launch, how long are you going to want to support the current version you're on too something you want to think about as well, even though that's a future consideration,.

Tim Bornholdt 11:05
Right. It's all things that'll impact your upfront budget of planning in advance how far out you're going to support. Another thing you'll want to consider is if you're building a web component, you need to support specific browsers. Now, are you trying to just target the latest and greatest, just Chrome and Safari and Edge and Firefox. Or are you trying to make sure you get back to legacy customers. If you're in an enterprise, maybe you have to target Internet Explorer eight, or, you know, God forbid, seven or something even further back. You just really need to make sure you have those considerations in mind, because the older platforms that you have to target and the more platforms you have to target, the longer it's going to take to build and test your app.

Rob Bentley 11:47
And that's a real thing. We've been asked if we can support Netscape before.

Tim Bornholdt 11:53
Which I'm a fan of. I love Netscape. That was my browser back in the day.

Rob Bentley 11:57
Well, yeah, it was good back in the day,

Tim Bornholdt 11:58
Not so much for 2017. But I think Marc Andreessen is doing pretty well for himself these days.

Rob Bentley 12:04
Another thing you have to consider is how many users do you expect to have right away. A system that handles millions of users and a server that can handle many requests at the same time has a different build and more things to consider than just an app that has maybe hundreds of users or even 1000 or a few thousand?

Tim Bornholdt 12:24
Yeah, supporting 100 users, you can get away with really one server, like one computer running your entire app. If you're supporting a million, you need to have multiple computers coordinated together to sync all that data and make sure everything is stable and secure for all of your customers. So it is two totally different builds. And when you're building out an MVP, a minimum viable product, that's going to be a lot easier to build out then building out a very full fledged system that's going to support a lot of users.

Rob Bentley 12:53
And if you have that many users, are all those users speaking the same language, or is some of your user base, going to be speaking Spanish or Hmong or Somali? You know, we have an app that we're in progress on right now that that's the next feature we're building in it is localization.

Tim Bornholdt 13:10
Yeah. And that's a great segue. That's why I laugh. Yes, your use cases are going to vary for this. I think a lot of customers are probably just worried about English to start. But depending on what service or goods you're offering, maybe you do want to focus on adding in Spanish or Hmong or German or Arabic or 100 different languages. The more languages you have to support, though, the more testing and the more expensive that it gets to build, and the longer it takes to build.

Rob Bentley 13:37
And then what's really fun to talk about is legal requirements with your mobile apps.

Tim Bornholdt 13:41
That's my favorite.

Rob Bentley 13:42
It is you can talk about it then.

Tim Bornholdt 13:45
Yeah, I mean, this is something we'll talk about later. But when you're building an on demand app specifically, you have a lot that you need to account for. Specifically, just all apps in general, you need to account for things like HIPAA or PCI compliance. That's probably the big one, when you're dealing with payments, you need to make sure that you're not, that you are storing people's credit card information as securely as possible. You also, if you're dealing with a governmental agency, you probably need to worry about section 508 to make sure that you're accommodating people with disabilities. So there's all kinds of legal things that you need to account for. And things change all the time. And the more that you can do your research upfront to make sure you're structuring your system to go within the right flow of those regulations, the faster the build is going to be.

Rob Bentley 14:32
Another thing you need to think about is how many other services does your app need to integrate with? And for this, we're talking about the the are you going to need like a "login with Facebook" button? It seems simple, but it adds complexity to the app.

Tim Bornholdt 14:45
And are you going to need to use turn by turn directions in this system? Do you need to hook into Google Maps? Or do you need to hook into a different company that has cheaper mapping options? Those are all real things. If you need to hook in with a third party push notification provider, that's another thing that you need to worry about. The more integrations you do with outside services, the longer it's going to take to build your initial version.

Rob Bentley 15:08
And then again, we kind of alluded to this before, but are you really going for a true MVP product? Or are you going to want to have more features in before you launch? Maybe you think your product doesn't need all those extra features? And that'll definitely extend the timeline.

Tim Bornholdt 15:22
Absolutely. And then finally, how robust does your search and data sync, push notifications, how robust do you need to have those features in on day one? For example, obviously, you need to have push notifications on day one. That's kind of a no brainer at this point in the game. But how many do you need how deeply integrated into the app do they need to be. If you can get away with basic notifications on day one, your build is going to get put out way faster than if you were trying to put out something with a lot of notifications that go deep into your app.

Rob Bentley 15:55
Or even stuff like when a user searches. Does your app let the user type whatever they want to the search bar and then hit a button that says search, or are you expecting it to be like Google and have all the like suggested results happening on every keystroke.

Tim Bornholdt 16:09
Right. That's two totally different build outs. So those are a lot of the things that will impact your development timeline from before you even begin development. But now, let's say we're in development, what are some factors, Rob, that are going to impact the release date, and perhaps push it back out a little bit further?

Rob Bentley 16:29
Well, the big one, for sure is change orders. And a change order is when we set an initial scope at the beginning, and then we find out we need to add a new feature or do something differently.

Tim Bornholdt 16:40
Yeah, and I can't recall a project we've worked on where there hasn't been at least discussion of a change order, but that's just how this goes, especially when you're talking about a 12 month build. It's impossible to predict every single thing that's going to go in to your app on day one. So change orders are going to happen and it's not a bad thing. It's just something that you need to account for and understand that if you change the parameters of a project after development has gone on, depending on what parameter you're changing, it could be impacting some pretty significant things. If you're changing parts of your app that are fundamental to how your data gets stored in the server, you know, that that could require weeks of rewriting stuff that's already been written in order to make sure that that new feature is done the right way.

Rob Bentley 17:26
Yeah, so change orders can be way more difficult to accommodate at the end of development rather than at the beginning.

Tim Bornholdt 17:32
And it's unfortunate, because most change orders come after you get the product in your hand, and you've been playing with it and you say, "Oh, this is how it should be." But again, if you do that work up front, that's going to mitigate the number of change orders that happen during the process.

Rob Bentley 17:45
Or you have users tested and they all decide they want this one thing really fleshed out. Whereas they don't care about the rest of your app.

Tim Bornholdt 17:51
That's a good point.

Rob Bentley 17:52
You can only know so much before you go into it. Then you learn while you're in the process.

Tim Bornholdt 17:56
Right. Another piece that's going to change your timeline during development would be, people... How do you put this in a nice way. People that make decisions on the app, you the person that we're talking to as the development team, you might be the person in your company that's the manager of the app that we're building, but you might not be the one that gets to approve things. So depending on how much red tape and bureaucracy and hierarchy there is in a company, that's going to dictate how quickly things get approved and things get done.

Rob Bentley 18:26
Or even just how many people you need to get an opinion from before you make a decision can weigh into it also.

Tim Bornholdt 18:31
Very true.

Rob Bentley 18:32
People get back to you at varying speeds.

Tim Bornholdt 18:34
Yeah, then speaking of which, our next point, depending on how many vendors you have working on your app, if you have an app that's really complex, you might be working with more than one development team. There might be one team was just working on the back end and one team was just working on the front end. And sometimes even one team working on one aspect of the front end and another one on the other, and if all three of those companies need to play well together and one company is not playing as well as they could be, that's going to impact the time that it takes for the final product to get out the door.

Rob Bentley 19:04
All the vendors can only go as fast as the slowest vendor.

Tim Bornholdt 19:07
Exactly. Another thing would be, there's kind of two coins on this. If you're working with bleeding edge, brand new technology that nobody has used before, and it's undocumented, that's going to slow down your development time. If you're working with let's say, Apple and iOS 11 came up with AR kit, which helps work with augmented reality tools. Nobody had done that. I mean people have done it, but no one had worked with that specific set of tools. So that's going to impact how long your product is going to take to get out the door.

Rob Bentley 19:37
Yeah, cuz there's other factors than just being able to display what Apple gives you right now. Apple themselves is still working on refining this, so how could we be that much farther than the company that gives us the ability to do it in the first place.

Tim Bornholdt 19:50
Exactly. And then conversely, like we mentioned before, not only bleeding edge technologies, but also working with really old technologies. If you need to support Internet Explorer seven or you need to support a very old version of Android because the boss is using a phone from six years ago, you know, that's really going to slow us down because we need to go back and make sure things work correctly and it just takes time.

Rob Bentley 20:15
Yeah, the boss having a really old phone is something we've run into more than we'd like to say. That's a real thing.

Tim Bornholdt 20:22
You think the boss of a company would be able to go out buy a new $200 phone, but I guess you don't get rich by writing checks. So now that we've gone through, kind of during the before development, and during development, here's a few tips that we've got for how to speed up the whole process and help get your app out the door faster.

Rob Bentley 20:40
So like we said at the beginning, the more well defined the app is the faster and quicker we'll be able to build it. So the what really you need to do is research.

Tim Bornholdt 20:49
Yeah, just know your customer, especially in an on demand situation. You're building a three sided marketplace, the three sides being the customer that's getting the service, the service provider who's providing the service and you, who's facilitating the service. So you need to understand all three components in order to really be successful. One, you need to understand how your customer's going to request those goods, what conditions are you going to put them in, and how in demand is your app actually going to be to provide that on demand service. As a service provider, you need to know how quickly can I get in and out of this app and provide as much service and provide whatever I need to do to get in and out and make my money as quickly as I can. And then as the middleman that's facilitating this whole thing, you need to understand how you can make money on this and figure out what percentage of sales you're going to take or what subscription fee you're going to charge in order to sustain this whole venture as you're going forward.

Rob Bentley 21:47
Right. So as well as having a high level of how the technology itself works, your job really is to nail down the business end while we build it out for you.

Tim Bornholdt 21:56
Exactly. So understanding from the technical side, then what really helps speed things up at the beginning is really falling in love with the minimum viable product process, and making sure that what path your users are most likely going to follow, whatever features are required to make that work, and by required, I mean, like, if you took it out, the app would just be totally useless, those are the features that you need to focus on building are the ones that help you get through that path. And then anything else that doesn't help a user absolutely get their thing done, those need to go to phase two, or three or four.

Rob Bentley 22:32
Right. As a project manager, if I know that your goal in mind is to release this MVP and release it as quickly as possible, two words, you'll hear from me a lot is "no" and "later."

Tim Bornholdt 22:43
And not at the same time.

Rob Bentley 22:45
And it's for your own good.

Tim Bornholdt 22:46
Exactly. So with MVP, really, you just want to understand that critical path from the user installing your app through getting the good or service accomplished. Ask if every feature actually, you know, gets that done. But then, finally, it's the thing that people usually get tripped up on with MVP is that they're thinking, "Okay, well big features. Obviously, like, if I'm going to add in a whole new sub component of features to the app that's going to slow things down." But it isn't just the big things that slow down an MVP, it's those little things like, "Oh man, we should really in our user profiles, make sure that they can add a link to their Twitter and their Facebook and their Instagram pages because that'd be so cool to have in the app." It's like little things like that are easy to do, it would take us five minutes to throw that in there. But it's all those five minute things, five minute things, five minute things that just add up and grow way out of control.

Rob Bentley 23:39
And be good about, you know, trying to stick to the original spec as much as possible and try not to change things up a lot during the middle of development to even if it's just, "Oh, can we change this color eight times?" It's like, yes, we can. But each distraction we have takes our thought and mental energy away from building out those critical features.

Tim Bornholdt 23:58
Right and there's always a time and a place to get those small things in there. And that's where you would work with us to really figure that out. And that would be our job as a technical team is to kind of steer you into the right direction of "No, that's not critical," or "Yes, that is critical. Let's do it."

Rob Bentley 24:13
Right. And we'll do all those little things. But the point is, we're just trying to help you figure out how to save as much time as possible.

Tim Bornholdt 24:19
Exactly. So we were talking about what you can do to speed this process up. And one thing that you were saying, Rob, is it's really making sure that you understand the business side of things. Going into that is also understanding the legal changes. Now, we have a perfect example of this. When we were working on an app for a client they were, there was a law that was passed. So they were doing on demand for dental agencies, and there was a law passed that specifically targeted companies that were dealing with dental hygienists.

Rob Bentley 24:48
Yeah and how they get paid.

Tim Bornholdt 24:51
It was like the most specific law that changed that you could get with this that impacted, it totally threw a wrench in the works and we had to strip out a ton of code in order to comply with this new regulation, and that threw off the timeline by a few weeks, and there was nothing we could have foreseen up front. But it's something that as you're going through this process, if you don't know the legal requirements, you need to find a lawyer, find an accountant, make sure you understand the tax implications of having drivers or service providers used as a contractor, versus hiring him as full time employees and seeing where that gray area is and finding out how comfortable you are in that area. And making sure that you're not setting yourself up if you build this awesome tool, well I guess, if we build this awesome tool from a technical side, and then you bring it out into the world and get sued into oblivion. That doesn't help anybody out.

Rob Bentley 25:43
It also doesn't help anyone if we get this awesome product launch and then no one uses it. So what you want to be doing in the meantime, while you're relying on us to get your tech built is to be going out and hunting down customers and making sure you have people to, you know, be able to meet the demand that you stir up.

Tim Bornholdt 26:00
Exactly you, you need to be able to fulfill, like we were saying before, it's a three sided marketplace, you obviously have one of those sides accomplished by yourself. But you need to go out and find people that are going to be getting the goods and services or purchasing them and asking them, what do you want out of this app, getting their opinions, getting their feedback, testing things out. Conversely, you need to be talking to the people who are providing this service and say, how can I make your life easier so that you're using my app and not somebody else who's building a similar type of tool.

Rob Bentley 26:29
So yeah, I guess that brings us to the final thoughts of the episode.

Tim Bornholdt 26:32
Is this how we're gonna call it. Final thoughts.

Rob Bentley 26:36
To summarize.

Tim Bornholdt 26:38
In conclusion.

Rob Bentley 26:39
I don't know. I mean, we could come up with a more fancy name for it. But I think Final Thoughts is fine. I don't think people really care.

Tim Bornholdt 26:46
No, I mean, if you care, you can write to us at hello@constantvariables.co and tell us what we should call our final thoughts segment, but we're just gonna call it final thoughts for now. Rob, what are your final thoughts?

Rob Bentley 26:59
Really, whatever timeline you get from a developer, you want to be thinking that it's going to take a little bit longer than that. And the reason for this is not that we're so bad at making estimates. We don't know how long it takes to write code; we do. It's just that all these external factors happen. Sometimes you get user feedback and need to beer up a feature, remove a feature. Law changes, like we discussed in the dental application. There's all kinds of things that can happen.

Tim Bornholdt 27:28
If you're working with something like Facebook. Facebook could all of a sudden one day snap their fingers and say, well, that thing that yesterday you could do, today you can't. That's happened time and time again in this space. It's still, it was what 10 years ago that we first got our our first iPhones?

Rob Bentley 27:44
Right.

Tim Bornholdt 27:44
This is a very, very young industry and things are still changing constantly. So it's not that we're bad at estimating time. It's that if the time that we would estimate is usually "Okay, here's best case scenario," padded in a little bit of time for unforeseen things. But maybe we should pad in more time. It's just so hard. We don't want to give you an unrealistic time. It's just, you need to understand that it's building any project that takes a long time, things happen. And we just need to be ready to account for that.

Rob Bentley 28:15
There are always internal and external reasons why a project might take longer. And we've gotten very good at mitigating the internal reasons. But sometimes with the external ones, there's not a whole lot you can do.

Tim Bornholdt 28:25
Exactly. The other thing to keep in mind with building out an app and how to lower the time it takes to build an app is that in software, you're never done. It's almost more art than science and that it's always it's constantly evolving. And there's you can always take a task or a feature that you want to put into this phase and push it down the road a little bit and really focus on getting the core pieces out and out the door. Don't think you have to get everything done for version one. People are not going to remember that you didn't ship with feature X on day one. As soon as you put it in the law forget about that.

Rob Bentley 29:01
Exactly. So don't get too caught up on it's not perfect or feature rich enough. The more successful apps are good at getting out there, getting users, and then just responding to feedback. Your users are always going to tell you what they want. Often will be things you never thought of yourself. Exactly.

Tim Bornholdt 29:18
I think that's good for episode one. What do you think, Rob?

Rob Bentley 29:20
Yeah, I'd say I'm ready to wrap it up.

Tim Bornholdt 29:22
All right, let's do this. Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter. Rob is @ScottMahonis. And this episode was brought to you by The Jed Mahonis Group who builds mobile software solutions for the on demand economy. Learn more at jmg.mn.