#9 What Does it Take to Make an App?

Maybe you have an app idea. What would it take to actually go from idea to production? Companies do it every day, but how do they do it? That's what we're going to talk about today. Welcome to Kopec explains software, the podcast where we make software intelligible.

All right, Dave, today's question, what goes into building an app?

And we're going to talk mainly about mobile apps today, right?

Yeah.

So I have a little bit of background in this. I worked as an iOS development consultant for a few years. That meant that people came to me with app ideas and I helped them actually go from idea to what we call a minimal viable product, which is a version of the app that they could actually get to consumers, or maybe just to beta testers that could verify whether there really was a business opportunity, a market opportunity for that product. So today I think what we should do is talk about the different roles, the different types of people that work on apps, and then talk about the different phases of development that they go through.

Sounds good. Let's dive right in. What are some of those roles?

So the four main roles that we're going to talk about today are developers. So those are the actual software engineers, software developers who work on the technical part of the app. So actually writing the code. Then there's the designers. They think about the user experience, the user interface, how the app flows, how the user is actually going to experience everything from when they first tap the icon to open the app to when they leave it to go to another app. Then there's also testers. They're people who make sure that the app works correctly. So they're like the quality assurance team. And then the last thing we need to think about is the marketer. So the business side, the people who make sure that we actually get information about this app out to consumers, they know they should download it. The people involved in advertising, the people involved in actually making sure that there's a business model that works for this app.

So how big can these teams be that are working on building an app?

So it can vary so much. So you can have somebody like me, who was a lone developer, working as a consultant, who was building apps on their own. And there's also people who are called indie app developers. And I do a little bit of that too, where I release an app that I built completely on my own into the marketplace. I'm doing all the marketing, I'm doing all the testing, I'm doing the designing as well. That is the exception, though, when you think about really popular apps. Most of the top apps that most people use are built by large corporations who have huge teams. If you think about a really sophisticated mobile app like Microsoft Word or like the Facebook app or Uber, those are going to have teams of hundreds, if not thousands of software developers working on them. And you might even have a huge team of designers, a huge team of testers, and a huge team of marketers as well. So actually, mobile apps can be just as big of a development process. We think, oh, just because it's on our phone, a lot of people think, oh, it's probably a smaller team than the people working on desktop software, enterprise software? Not at all. Building a mobile app can be just as sophisticated, just as complicated as building any other kind of software.

Will it be the same team regardless of the platform? Like, is there going to be one team for iOS and one team for Android?

Yeah, that's often the case. And we talked about this a little bit in an earlier episode. We talked about how developers tend to specialize in one platform. So there tends to be people who call themselves iOS developers and people who call themselves Android developers. Sometimes there are people who have specialty in both, and sometimes there are teams that use what are called cross platform frameworks, where they're building the app once for multiple platforms, but usually the case, especially at a large corporation who has the resources for it, you're going to have some developers and even designers who specialize in iOS and some developers and designers who specialize in Android.

So now that we have a sense of what these different roles are that are going to go into building an app, let's talk a bit about the process. What is the workflow from idea to app being a huge hit on the app store?

Oftentimes an app starts with a set of wireframes and a specification document. These are documents that show what is the flow of the app? What are the features of the app, how is the app supposed to work? So that when we actually get into the development phase, which is the next or third phase, depending on how you think about it, that we actually have a plan that we're trying to follow and we're checking as we go through development that we're matching that plan. So the specification document and the wireframes, which if you're a lone developer, might be pretty simple. You can wireframe an app up in PowerPoint if you need to, but usually we use more sophisticated tools than that. We use something like sketch. There's a lot of other design tools as well for building up the wireframes, but usually we have some kind of plan that shows, here's all the different screens, here's what's supposed to happen on each screen, here's the general features of the app, here's the third party frameworks that are being incorporated in the app. Here's what users are going to be able to do in the app. And this is all laid out in a very clear document.

So it's kind of like the goals of the app, right?

The goals of the app and the goals for development. Absolutely.

Okay, so once we have that list, and then we're bringing it to the programmers or the designers, what's the next step?

So the next step might be prototyping. So this is a phase where we're going to just see if the ideas can work. The developers might actually build something that we can actually run on our phones, people internal to the company or the team. And we actually see, is this possible? Especially if it's a more sophisticated kind of app? For example, most games will have a prototyping phase. Most apps that use some kind of new technology will have a prototyping phase where we actually see, is this even possible? Are our ideas doable in a reasonable amount of time? Can we get the basic concept working?

And prototyping, though is different than an MVP?

Yeah, I mentioned earlier the concept of an MVP. Oftentimes, especially indie developers, developers or small teams try to launch what's called a minimal, viable product before they launch a more sophisticated version of their app. This is going to be a version of the app that is meant for end consumers, but does not contain every feature that was originally envisioned in the wireframes and the specification. This is just going to be an app that proves that the marketplace is ready for this concept, so that there's actually a business model that works. You get the MVP out, you see that people actually want to download it, actually have engagement, actually use it, and then you prove the concept in the marketplace, and then you go and build out the rest of the features that you wanted. So when I was working as an iOS app consultant, that's usually what I was doing for clients. So somebody who had an individual idea or a small business that had an idea for an app, they would come to me and say, hey, can you build an MVP of this app? Can you build a minimal version of this app so that we can prove that there's actually some interest in our idea? And that is not always how a larger corporation will work, because sometimes they'll have the resources to build out a lot more features in the first version or they'll be porting the app from one platform to another. So if you think about something I mentioned earlier, Microsoft Word, right, when they came out with the iOS version of Microsoft Word, it was already pretty full featured because their consumers, of course, expected most of the features that existed in the Mac and the Windows version of Microsoft Word before the iOS version came out. So the MVP style of development is usually something that smaller teams or indie developers do.

So we've built this prototype and then what?

So we've built this prototype and then we're going to probably go through a long phase of development to go from prototype to the MVP. So that development can take a really long time in software. People are notorious in software for underestimating how long development actually takes. Believe it or not, that app that you think is pretty simple that you use on your phone every day might have taken months or even over a year to build. And it's really of course, going to depend on how big the team is, how sophisticated the app that's trying to be built is. So there's tons of variables involved and it's very, very hard to do the estimations because also we never know what kind of technical challenges are going to happen as we're developing the app. So these could be things like bugs that we encounter. These could be things like features that were more difficult to implement than we really expected. These could be things like integrations with third party libraries that we really didn't understand were going to be as problematic as they are. So all kinds of problems happen in development, and software is notorious for being late.

So development is kind of where a lot of the, the hard work happens and it's going to be the developers, the software engineers, working really closely with the designers at each step to make sure that you're meeting the specifications or even adjusting them if needed.

Absolutely. So the designers are going to be very involved, of course, in the initial specification wireframe phase. They're going to be very involved in the prototyping phase. But a lot of people don't realize they're actually going to be pretty involved in development too. There's going to be kind of a back and forth between the software developers and the designers. The software developers are trying to implement the vision of the designer, but they're also coming back to them sometimes and saying, hey, you know, actually we need to change the way that this works a little bit, the way that this looks a little bit due to technical limitations or we need to, we found actually as we go through development that we can make this flow this way. What do you think, design team? And usually there's a conversation there and a back and forth between the two.

Teams, so it's really a collaborative process, I guess, unless you're an indie developer. But I think we sometimes have this idea that the way something gets built is just this one person sitting in front of a computer, but in reality it's teamwork.

Yeah, and the other roles are coming in in this phase as well. So the testers, as we do development, are constantly testing new builds of the software, checking for problems. I want to talk a little bit more about the testers, because they're oftentimes an underappreciated aspect of software development. So the testers are the people who are doing quality assurance. They're making sure that everything really works the way it's supposed to work. And the software developers, of course, are part of testing as well. They might be building what are called unit tests, with check individual functions within the software to make sure it's really working correctly. They might be building UI tests, which are making sure the user interface really appears and works as it was expected to. But the testers might be actually a separate group of people. Sometimes they're people who have a background in software development or a degree in computer science, who are able to build scripts and build automated tests that make sure that the software works correctly. And sometimes they're actually just people who go and use the app and try to torture it, try to bend it and mess it around in every way that they can think of to ensure that every edge case is actually covered and every bug is found. Now, very rarely are the testers actually going to be able to find absolutely everything. No software really ships without bugs that's of any serious complexity. So we often have another phase in development called beta testing. And beta testing is when we might be getting builds out, not just to the internal team at the company of testers, but also to external users. They might not be our final users, they might be users who have some kind of insider track because they were users of previous versions of the software. They might be friends and family of the developers, but they're actual regular people, not people who are software developers, designers, or testers who are using the software and giving feedback. And oftentimes in the beta testing phase is when we're actually going to find a lot of the extreme edge cases that were hard to account for, even by the testers, because it's almost impossible for any sophisticated piece of software to really be anticipated in every possible angle that it might be used.

Feedback is so important to build something that's really ready for the public to use, because if you're not incorporating it and finding as many bugs as you can, then you're going to put a product out there that isn't very good and then it has very little chance of success in what is already a really competitive environment.

Absolutely. And I like that you said that it's a very competitive environment because it really is, which I think is a nice segue to our final phase. Our final phase is when you actually release the software and it's so competitive in the market that you can't really be a short of success just because you built a great product. There are over a million apps on the iOS app store. There are over a million apps on the Google Play Store. Whatever idea you have for an app or your company has for an app, it's very likely somebody else has already released an app like it, or they're working on it right now. This is where that last role that we mentioned earlier really comes in, which is the marketing department just releasing an app that's not marketing. It's not like that movie field of dreams. If you build it, they will come. You can build a great app and nobody will show up to use it unless you actually get the word out to the right people. It's just going to get lost in the shuffle. Now, there are some really specific ways that mobile apps are sometimes marketed. There's even an area of marketing called App Store optimization, which is ensuring that an app actually appears high up in search results on the various app stores. But there's also a lot of traditional marketing that needs to go into an app. Press releases, advertising, business models. All this stuff needs to be carefully thought about. And, you know, release is really critical the first day that an app comes out. The first week that an app comes out, it's kind of like a blockbuster movie. If it doesn't have good reviews when it first comes out, it can kind of get a bad reputation and never recover. And so it's really important that there's been a clear plan put in place for not only getting a lot of users after release, but also for making sure that you're incorporating feedback from users and continually fixing anything that goes wrong at release as well.

So can any app get released onto the App Store? Is that just open?

No, it's not. So both the Apple App Store and also the Google Play Store have reviewers who work at Apple and Google and make sure that apps are up to their specifications. What does that mean? Well, they don't allow every kind of app. For example, on the iOS App store, pornographic apps are not allowed. Certain kinds of hateful apps are not allowed as well. So they're checking for content, but they're also checking for malware. They're making sure the apps aren't viruses, they're not dangerous to end consumers. They're also checking for extreme bugs. Now, they don't do a perfect job at this, but they're at least doing a basic check to make sure that the app kind of works the way that the developers say it did. So there is some checks in place. There is kind of a walled garden approach where we're not just letting anything through and we're being careful about what actually makes it onto the app stores. That said, on the Android side, there's a way around this. And we talked about this in our episode on iOS versus Android. On the iOS side, all apps need to go through the Apple App store, but on for end consumers. But on the Android side, there's something called sideloading, where you can actually sell your app on your website, or users can download on their computer and upload it to their phone from their computer. So there's more than one way to get apps out there. There's more than one distribution model on the Android side, and you can get around this app review process.

So let's say that your app has made it through this approval process. It is on the app store, it's available to consumers. Is that it? Are you done? Do you ever have to look at it again?

So assuming you made it through the release phase and you marketed it. Well, I said that was the last phase, but I actually lied. The last phase is actually maintenance and continual improvement. So you come out with that. Maybe it's an MVP if you're an indie or small team, or maybe it's just a great 1.0 if you're a larger corporation, but you're not even close to done. Now you enter the phase where you have continual new versions and new releases as the app evolves. And why does it need to evolve? Well, if it's the case of the MVP, maybe it didn't have your full vision and you're continuing to add features as you prove out the initial concept. However, there's a lot of other reasons you're going to need to update the app. One is bugs. All software inevitably has bugs. That's of any kind of sophistication. So you're going to have bugs no matter who you are, no matter how talented a team you are, your software is going to have bugs, and you're going to end up releasing new releases to fix those bugs. You also might have security vulnerabilities, which you can think about as a kind of bug. They're not always your fault. It might be that the security vulnerabilities are in a third party library that you included, and you need to patch that library. And then there's one other thing that a lot of consumers don't think about, but there actually are incompatibilities with new versions of the operating system that can occur. I'll give you a couple examples from my own experience. Back in the early days of the iOS app store, we knew what the exact screen size of all iPhones was supposed to be. I think it was 320 by 480 pixels. Then the iPhone four came out, and the iPhone four had a slightly taller screen. So apps that weren't designed for the iPhone four's taller screen, they would have black bars on the top and bottom. And if somebody downloaded your older app, they would right away know you never updated it. You don't really care about your iPhone four users. Your app looks old fashioned. And another thing, the iPhone four had a retina screen, so it had a denser screen in terms of pixel density. That meant that your older app would look really pixelated on the new iPhone four, again, not looking great for consumers. So these kind of, that was just one example. But changes happen all the time. There's also something called deprecation. That's when Apple or Google decides that one of the APIs, including iOS or Android, is no longer to be used by developers. And usually they give you a warning saying, at some future point we're going to remove this, therefore it's deprecated, and you need to go and update your app to use a newer API. Otherwise your app will stop functioning. So the operating system vendors actually give us reasons that we need to continually update our apps if we want them to still be usable by consumers. So you're not done. In fact, the amount of work that might go into the maintenance phase or just adding new features phase could be more than the amount of work of launching the MVP. And oftentimes it is.

So there's a lot to build an app, there's a lot of work, there's a lot to get from idea to on the app store used by consumers. And then it's a continuing and ongoing process. So what advice would you give to someone who says, all right, I've got this app idea you know, I was.

Dealing with a lot of people like that and I don't want to put them down or you down, the person listening who has an app idea, because you might have a really great app idea, but it's a really big process. And if you don't have any of those skills yourself. So you're not a developer, you're not a designer, you don't have any experience in testing, you're not a marketer, then all you are is somebody supplying money and an idea, and you're going to have to hire all of those people. Maybe you find somebody who's able to do two of those four roles. Maybe you find somebody who's able to do all four of those four roles. Pretty unusual, though. If you can find somebody like that, and then even when you find somebody, how do you know that's really a good person? How do you know that's a good developer, a good designer, when you don't have the skill set to really be able to judge who's good and who's not good? So it's really a challenge if you're just a lone person with an app idea. What's really best is when we have teams of people who each bring something to the table. So if we have somebody who comes in who's a designer and works together with a developer, or somebody who's a really good marketer, who works together with somebody who's a developer, when we have somebody who brings some skill sets to the table, it's a little bit easier to actually get something into production. But the other thing you need to know is it's a super competitive marketplace. I mentioned earlier just how many apps there are. Just because you build a great app too. If you don't have the business acumen or the money to spend on advertising, it's hard to acquire users. So a lot of the stacks are up against you. It is not easy to take an idea and turn it into a successful app. And you should know that's probably going to be a pretty expensive process, especially if you can't do any of those four roles yourself.

I think that's good for us to think about and keep in mind when we're all saying, oh, there should be an app for that, or why isn't there an app for that? Or this app is so simple that actually it's not that simple and it has been lots of work and lots of different layers to it.

Yeah, that's the biggest misconception that I found the general public has, is they just don't realize how complicated, how complex, how sophisticated, how much work goes into every one of those mobile apps that you use on your phone. It is just as complicated a process as any other strong engineering discipline. So it's hard to. I'm not going to go call out specific engineering disciplines, but you probably think building a car is complicated. Well, I'll tell you, building Microsoft Word is probably as complicated as building a car.

Good to know.

Well, we have a new Twitter account, right?

So our Twitter account is opecexplains. That's O Pece explains. So follow us and let us know if you have questions or ideas for the podcast. Maybe we'll be talking about them in a future episode.

You know, Rebecca and I have a huge backlog of ideas for episodes and things that we're cooking up and working on, but we'd love to have your ideas, too. We'll put them in the hopper and the they'll probably come out at some point, too, if it's a great idea. Podcast is still growing. Don't forget to like us on your podcast player of choice, whether that be overcast or that be Apple podcasts or Spotify or Google podcasts, just go in there and give us a like, and that really helps the show. And thank you to everyone who's already done that as well. Well, thanks for listening, and we'll see you next week.