62: Development Milestones, Tangibles and Timelines

Ever been hosed by a developer? It’s an unfortunate story we hear time and time again. Understanding the high-level milestones associated with most development projects can give you confidence in knowing your project is on the right track. In this episode, Tim chats about the tangible assets you should expect to receive at each development stage, along with a fair pace for completing each stage.

In this episode, you will learn:

• What tangibles you should receive from each stage of development
• How long each development phase should approximately take
• When to expect something visual versus a verbal update

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded January 14, 2021 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Notes:

• Building a Business & Community with Intention with Mike Jackson of Black Tech Talent
• App Development Lifecycle Series

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at things technical. I'm Tim Bornholdt. Let's get nerdy.

Before we jump right into this week's episode, I have a small favor to ask. We are conducting a survey of you, our listeners, to hear your thoughts on the show and to help us plan content and guests that matter to you. We also would like to know what some of your favorite podcasts are that you listen to. So if you have a minute, please head to constantvariables.co/survey. Heck, you could even fill it out while you're listening to this episode. That's constantvariables.co/survey.

Today, we are chatting about what you should expect from a development team at specific milestones. So this episode was inspired by a chat we had on a previous episode with a non technical founder named Mike Jackson. We'll link to that episode in the show notes. But in short, he selected a development partner whom he was led to believe had the capabilities to build out his idea. He started paying a monthly fee and eventually got kind of hosed when the developer wasn't meeting deadlines or showing any progress. And this is a story that we hear over and over again. And it doesn't matter if you're an entrepreneur, or you're in a large organization, these types of companies that come in and promise the world and ultimately can't deliver, we hear this all the time.

So in that spirit, we thought we'd talk about what you should expect to see from your development team at specific milestones, so you know your project is on the right track. While trust in your development team ultimately plays the biggest factor in a successful project, here are some tangibles you should expect to receive along the way, regardless, if you're heavily invested in the development project, or you're more hands off.

First off, we're going to base these milestones around the five stages of app development. So again, those are strategy, design, development, testing, and deployment. We've previously talked about each of these stages in depth in previous episodes. And obviously, we're going to link to those in the show notes. But each stage individually produces very tangible results. Another thing to note, before we really jump in here, these milestones are very dependent on your project. If you have a smaller project, you can expect the turnaround to be faster than a larger project. And this is part of the problem with the milestones is that every app is different. So it's hard to keep a consistent timeline. But I think you'll hear what we do here at The Jed Mahonis Group and hopefully, that can be something that most development shops also follow as well.

So first, we'll talk about strategy. The first thing you should receive from your developer is a strategy for how they plan to build your app. Really, you want to get down to how have they solved similar business problems. Knowing this gives you confidence in their ability to equally build a product that solves your business needs. So usually, the tangibles in this process would be some sort of strategy session where they actually talk with you and figure out what you want to have built, then they come up with user stories. So these user stories, if you are unfamiliar with the term, are basically a list of informal natural language descriptions of the features of a software program. So you might say, for example, a user story might be as a user, I would like to sign into the app so that I can conduct my business. That's a very straightforward and capsulated description of one feature that then you can go and test later on.

Another tangible from the strategy side of things would be wireframes that represent those user stories. So just like blueprints of a house, wireframes are written out, just skeletons of how an app would work and look. Again, design comes down to not only the way it looks, but how it works, and how the pieces all flow and fit together. So wireframes are a visual representation of those user stories that are used in later phases.

An estimated time for getting through this phase, depending on the size of your app, I would say it's between one to four weeks. It can take up to six weeks if you have a very large app, but most of the time we can get through this phase within a couple of weeks.

Next is the design phase. So the tangibles out of here are probably pretty obvious. You're looking at user interface and user experience mock ups. Often these are clickable. We call it a clickable prototype. We typically make a mock up clickable when it's a complex app so you can see how all the parts fit together, especially from your perspective as the user and from our perspective, as the developers, we want to all be crystal clear on what happens when you click on each thing so that we're sending you to the right part of the app.

Another tangible that you would receive is an asset catalog. This is typically the icons, the logos, the graphics, anything inside the app that we don't generate by code, but is rather, you know, like a PNG, or an SVG, those would be delivered in the form of an asset catalog.

And finally, you'll also receive usually a static PDF of those markups. So if it's not a clickable prototype, you'll at the very least get a PDF of each of the screens. One thing I'll note in the design section is oftentimes we don't actually design out like the settings screen or like the privacy policy screen. So you might not expect a complete version of those designs because it's just not necessary. We can design, you know, one screen and say the rest of them are going to look similar to this screen.

The estimated time for this phase and when you can expect these deliverables, again, depending on the size of your app, I would say anywhere from two to six weeks. I would say we typically get more on that two week side of things. But again, if you want to account for any revisions or changes that you might want to make to it, you may want to budget closer to the four to six week side of things.

Next, we move on to the development stage. So this stage is typically the longest, especially with a brand new build out of an app. The tangibles would be demoing each user story on your device. You remember, we talked about user stories back in the strategy section. So each user story should be able to be demoed on a device.

The estimated time for this one, I would say you should expect a demo of new or improved features at least every other week. Typically, development shops work in two weeks sprints, especially if they're like an agile type of shop. And you can look at previous episodes to hear more about agile development. But I would say, again, you should expect to be demoed some of your new features and just see progress at a pace of at least every other week.

I would also say upfront, don't expect to see something visual every week, as at least half of app development is stuff you can't see. So things like how the database works on the back end or how the API works, there's all these kind of parts that you don't see anything. So unless you want to look at a command line with some SQL queries to a database, you might not see stuff right away, but they should at least be able to explain to you what got accomplished during the last phase of the development stage.

Next, we will discuss the testing stage. So once we've entered the testing stage, your development team is going to ask you for a list of internal and external users. So internal meaning anyone in your organization, you know, if you're an entrepreneur, it would be your investors or anyone that you want to see that's actually on your team in your company. External users would be if you have focus groups, or people that don't necessarily work for your company, but are trusted users. So like if you want your spouse to check out your app, or you know, any friends that you have, that would be an external user.

Now, whether you're on iOS, or Android, each of them have their own testing structure for getting apps onto your device. So on iOS, for example, you'll be set up with a TestFlight account, because that's what Apple uses for TestFlight. Google uses Google Play to distribute beta builds of your app. So at the same time, your development team should be setting your Google account up so that you can receive these beta builds.

Now, for estimated time in this phase, obviously, at the beginning, you're not going to get a TestFlight build or a Google Play beta build, because the app's not really ready to use. But as you get closer to feature complete, you should be getting new TestFlight builds at least once every other week. And I would argue perhaps weekly, depending on the size of your app, but I'd say at a pace of at least every other week. And if you're not getting it at that pace, you should ask your development team what the reason is, because sometimes it might be that a lot of the issues again are back end. And so we need to fix the back end before we can fix the front end. There's all types of things, and so all of this is up for communication with your development team. But again, I would say that a fair pace that you can set as an expectation would be getting a new TestFlight build every other week.

And finally, the deployment phase. So tangibles from this phase should be pretty obvious. Deployment means that you have a live working app in the App Store. So the tangible here would be going into the App Store and seeing your app.

Now as for estimated time, this gets clearer as you get closer to the end of the project. Often there's an old saying that the last 10% of a project is 90% of the work. And the reason for that is that you end up finding a lot of issues or things that don't feel right, or you realize, Oh, we need to get this one last thing in. There's always stuff that muddies up when things actually finally get delivered. But again, this deployment timeline is going to vary depending on your app. But basically, once you're in that testing stage, and you get a feature complete app that's working well, then you can deploy it out and you should be good to go.

Some final thoughts. Development shops have different approaches for development. But generally speaking, this is a pretty standard way for building software. The important thing is that whatever milestones your team sets, you're both clear on what is going to be delivered and when it will be ready. Everything with software, and especially when you're working with a different team that's not internal, I mean, even if you're working with the team that is internal, having clear milestones, and understanding at least how software gets developed at a very high level will help you in doing your job, whether it's planning for marketing releases, or getting your users on board or revving up your support team. Those are all things that need to be coordinated in concert with the development, so open and clear communication, again, is what makes projects succeed.

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 and the show is @CV_podcast.

Today's episode was produced by Jenny Karkowski and edited by the gallant Jordan Daoust. If you have a minute quick before you leave, we'd love it if you left us a review on the Apple Podcast app. It shouldn't take much time at all, and it really does help new people find our show, just head to constantvariables.co/review and we'll link you right there.

This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn.