Really Complete a Prototype

A prototype done is not a prototype ready to ship.

Even with our quick start approach, we need at least a little bit of time to prepare your app for users.

To make that happen, today is all about the little stuff that most of us would rather skip over but that could easily sink your project before it really gets started.

We're going to discuss the ins and outs of project management 101 – keeping all of this stuff organized so it doesn't get out of hand as it grows – and QA and bug fixes. Essentially, the stuff you should be doing actively right now to get your app ready for the people who will be using it.

Skip these steps at your own peril – they will be the things that ultimately help you stay ahead of the curve and get something quality into the hands of your users.

Project Management

Whether you are building the app yourself or hire a contractor to do it for you, you need a plan in place to manage the development process, oversee new tasks that come in related to cleanup or fixing your app, and organize all those resources you've been juggling for a week now.

Yes, this applies just as much to yourself as it does to a contractor (possibly more so). Don't skip this stuff because it's going to help you stay on top of the little things that all too often fall through the cracks.

The first thing you should know about a project (any project) is that it will take twice as long to complete as you have planned. It will also cost twice as much (if you're paying someone to do it for you).

Not to be a total downer at this stage of the process, but you'd better be prepared for things to fall apart at the very end when you have a deadline in place that will almost certainly be missed.

The solution?

Back into it. All good project managers know not to trust the dates provided by their creative and development teams.

Stuff happens, and the people who build stuff are always overly optimistic. You will be too.

If someone tells you it will take 5 days, assume it will take 7-10. If you really need it done in five days, ask them to do it in 2-3. Is it foolproof? Not quite, but it's a lot better than missing your deadlines by a week or more because of unrealistic expectations.

Here are a few more tips to help keep your project organized and under control until the moment it finally ships.

1. Log Everything in a Central Resource

Don't trust your email. Heck, don't trust anyone's email.

The biggest mistake you can make is to get lax by allowing all of your communications to live where they live. Good project management involves pulling all of the resources for a project together into a single shared space.

That shared space is not your email because it's way too easy for someone to lose, delete, or forget an email ever existed.

You don't need anything fancy though. Google Drive's shared folders, a Dropbox account, or Trello are all very effective (and free!) tools you can use to organize files in a shared space. The big stuff has features you'll never use, at least not until you have a team of people to keep organized and on point.

2. Communicate Constantly with All Parties Involved

Communication is the biggest gap in any type of project. People get lazy and they forget to reply to emails, leave out valuable information, neglect to followup, or simply drop the ball on their deadlines.

To avoid this happening, be as open and transparent as possible with constant communication to everyone involved.

Aim to send a followup email to cofounders or contractors every couple of days with what you're working on and if there are any issues with the project. Even if there are not issues, followup, because it will keep people engaged and the project top of mind.

3. Have a Timeline in Mind, But Don't Stick to it too Sharply

 A good timeline is important, but it's not set in stone.

In fact, the fastest way to piss yourself off and stress out everyone involved is to treat your deadline like a line in the sand that cannot be missed. Unless you're launching something for a Fortune 100, you don't need to hit your deadline.

Better good than on time.

But having that timeline will give you something to work towards – a shared responsibility that you can push each other to meet. This is especially important if you are working on this alone or with a cofounder (contractors are getting paid - they had better respect your timelines).

4. Test Frequently to Ensure Your Investment is on Point

This is the biggie.

Everything we've talked about from day one until now is testing and retesting your idea. Every step of the process you should be stopping and reviewing if what you've planned and developed is in fact what you need to have from the project at that stage.

Your hand drawn walkthroughs, your wireframes, your run through with family members, and now the testing of the actual software – it's all vital to make sure you are as close as possible to what you expect at every stage of the process.

If you're not where you want to be right now, then consider why that is and take action. Don't find out when it's too late.

5. Save Everything for Future Reference

Don't throw anything out. Save your drawings. Save your emails. Save the first version of the app. Don't toss stuff out just because it feels like you're done with that step.

There's always more work to be done and you never know when you might need to look back at something you did several days or weeks earlier to find out where a problem might have cropped up.

Will you use most of this stuff? Probably not, but better to be prepared than not.

Managing Yourself on a Daily Basis

All this stuff is incredibly important if you are managing a team of people, or even just a single contractor that you have never worked with before. But what about yourself. What do you do when you're working alone and don't have to report to anyone but yourself?

You get even more strict.

Listen, you don't to be overly harsh on yourself. Stay positive and encouraging to ensure you actually reach your goal, but at the same time, don’t let yourself slack off and procrastinate.

Treat yourself the way you would treat a contractor and stay consistent in those expectations. Here are three things you can do to help do just that:

• Realistically Measure Available Time – Be realistic and map out how much time you have available on a day-to-day basis. Don't schedule for more than you have available to work, and don't expect yourself to be more productive than you have been historically.
• Use a To Do List Tool to Track Availability – Snag a free tool like Toodledo or Todoist and create a list of stuff you need to get done. These tools are super flexible in that you can create folders, priority levels, and filters or you can just manage a list of stuff to work on – both have mobile apps for both major platforms.
• Work with a Partner to Keep You Accountable – Having a business partner is good for one more thing. They will keep you on point; forcing you to actually get work done as there's a person you'll now feel accountable to if you drop the ball.

Do these three things and you will be 100% more productive than if you worked completely alone. It won't solve every problem (you are human after all), but it will reduce the risk of there being a huge issue because you felt like playing Call of Duty instead of coding one day.

Managing QA for Your Project

Like I said, testing is the backbone of your project.

Without testing, you'll never know if what you're doing is working or if you're way off base. Better to find out now that your app is busted in a hundred different ways than the day after you launch.

At this stage of the process, you've moved past pre-testing and into actually testing a (hopefully) working app for bugs. This can be brutal, especially if you did the coding and felt any sense of relief when the project was "done".

The goal of good QC is to have frequent, organized testing that looks for bugs, actively tries to break the app and uncover what vulnerabilities are there, and ensure that the software will work as intended for everyone that will soon be downloading it.

Testing in QC

What exactly should you be testing? With each version of your app, there should be a number of tests run to ensure the app is working as intended.

To get started, go back to your wireframes and review your screens. Look for original notes you had about potential issues or questions you had about functionality. Now create a checklist you can use to compare those original drawings to the finished product.

The goal here is to make sure what you outlined is exactly what you produced. If the two don't match up, why? Is it because of logistics, or is there a problem?

Try to Break Your Baby

Software is made to be broken. Seriously, find a single major release that hasn't been broken (intentionally or otherwise) and I'll show you software that no one actually used.

If an app is good and solves a problem, it will have a lot of users, and a lot of users mean a lot of different use cases. The sheer volume of ways people will use (and misuse) your app is mindboggling, so of course someone will find a way to break it.

The goal of QC is to find as many of these app-breaking circumstances as you can before it gets into the hands of anyone who paid for it.

The more easily the app can be broken, the more likely a paying user will stumble across the bug. The really rare, hard to replicate stuff is important too, but it affects fewer people. It's a numbers game. You don't want to piss off any customers, but if it's going to happen, the number might as well be as small as possible.

So how often do you test the app for these issues?

Every time you get a new build back, it should be put through its paces.

Use the checklist above to go through every possible situation with the app and ensure it works as intended. Take note of everything you see out of the ordinary, whether it breaks it or not. Sometimes a seemingly small hiccup could turn into a much bigger bug in a certain environment – a different version of the operating system, a different hardware configuration, or other apps that interfere with system resources.

It's impossible to test for all of this stuff on your own, so the better your notes, the easier it will be to find those issues when they inevitably pop up.

Record Your Actions

Keep a log of your activity in testing.

There are powerful tools out there for bug tracking – you don't need anything nearly that powerful (yet), but you should have some sort of central database to track stuff.

Trello is a great tool for this because it can track bugs as well as those you are working on and those that have been fixed or retired down the line.

However you do it, make sure you're using some sort of centralized resource that can record all of your bugs together. If you bring someone else on board or start outsourcing any part of this activity, you want every member of the team to see all the work you've already done.

The second important part of this process is prioritization.

By having all your bugs logged in one central source, you can organize them by priority more easily.

At this stage, you really only want to worry about the "critical" stuff – the stuff that will absolutely break your app and make it impossible to use. There will be some pretty nasty, prevalent bugs in there that you end up having to ignore because they are more "annoying" than "catastrophic".

It's part of the game.

The better you can organize, the better you can ensure the big bad stuff is dealt with first.

Managing Bug Fixes

This process is all about identifying the biggest possible problems you might have and tackling them in the order they appear (based on priority).

In short, if something is going to completely ruin the experience of using your app, it had better be at the top of your list to fix, not buried behind a bunch of cosmetic problems that you happened to notice first.

You will not have time to fix them all – just work on the ones that will result in refunds and bad reviews.

What's Critical?

So how do you define critical and bury some bugs that are going to be frustrating, regardless of how often they are noticed?

Easy enough – you answer two questions:

1. Does it break the app?
2. How many uses does it affect?

The combination of 1 and 2 will determine how critical the problem is and where it should be listed in the priority order of your bug log.

A bug that breaks your app but only appears in a very rare situation and has only affected one user is not as important as one that affects dozens of users because it happens relatively frequently.

There may even be some bugs that don't break your app but that affect a large enough number of users that they need to be moved up the priority list and dealt with sooner than later.

This will be entirely up to you, but if you think about your users and their experience above and beyond all else, you'll get a good sense for how seriously to take each of these problems as they occur.

Fix the Critical Stuff

You're on a budget.

If you're doing this yourself, you only have so much time. If you're paying someone to do it, you only have so much money.

So the number of bugs you fix will depend entirely on how much of either you can invest at any given time.

It's going to be costly if the app is super broken, but those are the things you need to fix before you have a truly effective prototype that can be launched to your first users.

To avoid overstretching yourself and your resources, now is the time to draw a line in the sand and only work on those bugs that absolutely must be fixed.

Even if you have more money or time to address more of these bugs, your cut off should be at the orange labeled bugs. Anything below that can wait. You'll need the time, trust me.

Just Ship It

Only two things matter in software – that it exists and that it looks good while failing.

The bug list above can be a source of major stress for a developer who wants the app to look and feel as good as possible before it gets into the hands of paying users.

But the longer you wait, the more this thing costs you.

Worse yet, if this thing is going to fail, you want to know now, not a few weeks from now when you're finally ready to put it out there. Why spend that much extra time and money on an app that is destined for failure?

A little harsh? Yeah, but it's the truth and the longer you can keep that in mind, the better you're going to perform.

There's a reason you're building this thing in one week and not one month or one year.

Get it done, get it out there and learn whether it's going to succeed or not.

So what do you need to actually ship your app?

Not very much.

It should work. It's one thing to send an app out the door with bugs still in the system, but another entirely to ship it when you know it's going to break for a large percentage of your buyers. This can hurt you in several ways.

Bad reviews are a problem but can be glossed over with time, but more than that, the users most likely to enjoy your app and become evangelists for it are the ones who download it first. So if your app is busted out of the box, you're going to lose a lot of momentum you could use to grow your business down the line.

So you want it to work, at least well enough to fulfill the basic promise of the tool.