How Long Does It Take to Build a Mobile App (Podcast)

How Long Does It Take to Build a Mobile App (Podcast)


Welcome to constant variables, a podcast
where we take a non-technical look at mobile app development.
I’m Tim Bornholdt. And I’m Rob Bentley. Let’s get nerdy. So constant variables,
Rob, why are we doing this podcast? Well first a little bit about us. We started a
company called The Jed Mohanis Group about six years ago and we specialize in
building mobile apps. 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.”
Yeah so today we wanted to talk about how long it would take to build an app,
but not only just an app, how long will it take to build an on-demand app. Yes
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
will 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. Right so
we’ll start with what is an on-demand app? Yeah so real quick what we mean by
an on-demand app, think of something like Uber, Dominos, 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. This applies to a lot of different industries and markets/ Obviously
ride-sharing is a big one because everyone’s heard of Uber food deliveries, another big one right now. Yes it’s been delivered for a long time now but
now other restaurants are starting to get into the space as well. Exactly but
not even just those apps. There’s a lot of services that could apply to on
demand, so you know even think like 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 other ideas you can
could draw from here really so it applies to a lot of industries. 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. Right going along with the instant feel of how everyone
feels like they should be able to hit a button and get whatever they want,
whether it’s a good or a service. Exactly so what does it take to build an
on-demand app, what are the different pieces that you need to make that happen. 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, the 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. So yeah with the front end you know when you’re talking about the customers,
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 we’ve built both. It’s pretty common. The service side though with
doing an 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 ondemand;
they’re not tethered to a laptop. Right to your location too. 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 other 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’s facilitating that matchmaking. And just for the people that don’t know to
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. Right I mean if you’re getting into
this space we’ll make it as non-technical as we can but you’ll also
need to kind of know some of the the lingo but we’ll break it down where we
can. Also um when we’re talking about the back end, another
component that we’ll 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’ve 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 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 gonna be dealing with implementing push notifications; this
means users get notified when their orders received. People that are
fulfilling the service get notified that there is an order to fulfill. All that
kind of stuff. Yeah keeping all that data in sync so as soon as, if they aren’t
responding to a push notification, if they just open the app the data is
current. Search, which would apply if you’re shopping like getting food from
grocery store, yeah, being able to find bananas easily. Well 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
your 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 uh direction for that. Right if you need a brain surgeon right here right now a pediatrician probably
won’t be your best bet. Yeah you need an on-demand brain surgeon. I guess someday somebody probably will. I mean that’s where we’re going. That’s true and then
also mobile payments 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. 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. If you have someone’s payment details
getting leaked that’s basically the end for you. Yeah exactly 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. Yeah yeah I guess that
is that it for all the technical components. 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 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 on-demand app? 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 3 to 6 months. Ok makes sense. 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. Sure so really the 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 they’re looking more towards
that six nine twelve month range, really depending on on the the specific app
that you’re building. 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. So 3 to 12 months that’s kind of a wide range there. What
are some things up front that that’ll that we can basically gauge the timeline
that we can say it’s gonna be more like 3 months or it’s gonna be more like 12
months. What are some of the factors that will go into dictating that timeline? 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 a finalized product, the quicker it’ll go. Yeah so really it’s 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 gonna take to get somebody in the door. It’s not
just having the general idea. It’s really thinking through what we in the biz call
a user story and having thinking of the user in mind and thinking I’m going to
pull out 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 in making it so that it’s the most efficient process possible to get
somebody in and out of your app and accomplish the task that they need to
get done. 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. And thinking through the edge
cases with those as well because you’re gonna have a path a 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 that 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 the 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 4, probably not, but maybe
you’d want to go back to 9 maybe 8 depending on your specific cases and
needs. So just keeping those things in mind. Also once you launch how long are
you going to want to support the current version you’re on too is something you’ll
want to think about it well even though that’s a future
consideration. Right it’s all things that will 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 8 or you know God forbid 7 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 your your
app. And that’s a real thing we’ve been asked if we can support Netscape before. Which I’m a fan of, I love Netscape, that was my browser back in the day. Well yeah it was good back in the day, not so much for
2017. But I think Marc Andreessen is doing pretty well for himself these days.
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 a thousand or
a few thousand. Yeah supporting a hundred 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 gonna be a lot easier to build out than
building out a very full-fledged system that’s gonna support a lot of users. And
if you have that many users are all those users speaking the same language
or some of your user base is 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 or ability and it’s localization. Yeah and that’s a great seg, that’s why I laugh your yes your use cases are going to vary for this I think
a lot of customers would probably just worry 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 a hundred 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. And then
what’s really fun to talk about is legal requirements with your mobile apps.
That’s my favorite it is you can talk about it then 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 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 do you are
you going to need like a log in with Facebook button it seems simple but it
adds complexity to the app 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 gonna take to build your initial version
and then again we’ve 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 absolutely and then finally how
robust does your search and stay is saying push notifications how how
bust 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 gonna 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 or even stuff
like when a user searches does your app just let the user type whatever they
want to the search bar and then hit a button that’s a search or are you
expecting it to be like Google and have all the like suggested results happening
on every keystroke right that’s two totally different build outs mm-hmm 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 around that are going to impact the release date and perhaps
push it back out a little bit further well the big one for sure is change
orders and a change order is when we set an initial sculpt at the beginning and
then we find out we need to add a new feature or do something differently 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
the 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 yeah
so change orders can be way more difficult to accommodate at the end of
development rather than at the beginning 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 upfront
that’s gonna mitigate the number of change order
that happen during the process 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 that’s a good point you can only know so much before you go
into it then you learn while you’re in the process right another piece that’s
going to change your timeline during development would be people how do you
put this in a nice way and people that make decisions on the app you the person
that 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 gonna
dictate how quickly things get approved and things get done or even just how
many people you need to get an opinion from before you make a decision can
weigh into it also very true people get back to you at varying speeds yeah then
speaking of which our next point um 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 backend 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 gonna impact the
time that it takes for the final product to get out the door all the vendors can
only go as fast as the slowest bender 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
gonna slow down your development time if you’re working with let’s say Apple and
iOS 11 came up with a our 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 gonna
take to get out the door yeah because there’s other factors than just being
able to display what Apple gives you right now Apple themselves is still
working on refining this right we be that much farther than the company that
gives us the ability to do it in the first place exactly and then conversely
like we mentioned before not only bleeding edge technologies but all
working with really old technologies if you need to support Internet Explorer 7
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 gonna slow us down
because we need to go back and make sure things work correctly and just takes
time 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 you’d 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 yeah so now that we’ve gotten 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 your app out the door faster 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
yeah just know your customer both especially in an on demand situation
you’re building a 3-sided marketplace you’re 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 is 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 thats 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 right so as well
as having a high level of how the technology itself works your job really
is to nail down the business and while we build it out for you exactly so
understanding from the technical side then what 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 past 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 that’s 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 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 to words you’ll hear
from me a lot as no and later and not at the same time and it’s for your own good
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 gonna 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 cuz 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 and grow way
out of control 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 too 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
right and there’s always a time in a place to get those small things in there
and that’s 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 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 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 for dental agencies and there was a law passed that specifically targeted
companies that were dealing with dental hygienists it was like yeah I get paid
it was like the most specific law that change 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 upfront
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 them 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 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 it also doesn’t help anyone if we get this awesome product launched 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 exactly 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 gonna 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 so yeah I guess that brings us to the final thoughts of the episode
is this how we’re gonna call it my final thoughts to summarize in conclusion yes
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 no I mean if
you care you can write to us at hello at constant variables Cohen 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 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 yeah 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 beef up a feature remove a feature law change it’s like we
discussed in the the dental application there’s all kinds of things that can
happen 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
still it was what ten years ago that we first got our our first iPhones right
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 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 I guess
it’s 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 count for that 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 exactly the other thing to
keep in mind with building out an app and and how to lower the time it takes
to build an app is that in software you’re never done it’s it’s it’s almost
more art than science and that it’s always it’s 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 have ship with feature X on day one as soon as you put it in
they’ll all forget about that 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 gonna tell you what they want and it often will be things you never
thought of yourself exactly I think that’s good for episode 1 what do you
think around yeah I’d say I’m ready to wrap it up 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 [email protected] I’m @TimBornholdt on Twitter. Rob is at @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

Leave a Reply

Your email address will not be published. Required fields are marked *