Complete a Prototype (A minimum viable product)

Today is about building a product that you can feel good about. One that works (mostly) and with which you can start collecting feedback from users.

It's about pulling everything we've been talking about together and creating something amazing.

As you can imagine, there's a lot to it. From knowing what the prototype should look like to developing a strategy for getting feedback, and actually building your app, there's a fair bit to juggle.

But everything we've talked about the last five days builds to this. You know your product inside and out by now. You've used the app (on paper). You’ve solicited feedback. You have a kickass wireframe.

It's time to actually get stuff done.

When this process is done, you'll not only have a working prototype, you'll be one step closer to launching your product and getting the kind of feedback needed to build it into something truly special.

But first it has to be built.

For that you're going to need a full breakdown of the app, what it looks like, what it does, and an idea of who is going to build it.

What to Include in Your Prototype

Your prototype should do several things, but there are even more things it should NOT do.

The goal is to create a product with the bare minimum of features needed to do what it was designed to do. The cool idea and problem solving feature you brainstormed back on Monday should be there, but the bells and whistles?

Those need to wait.

As you can imagine, a prototype doesn't take particularly long (in the grand scheme of things) to build. It's small, agile, and easy to use. It's also probably broken in a few dozen ways and is missing at least half the features you originally envisioned.

But this is all good. Just having that working prototype in your hands is going to be the catalyst to do some very cool stuff – stuff that until today has seemed too far away.

To start, though, there are a few things that absolutely must be in place – the tools that will help you collect data and make sure all your hard work is being put to good use.

Monitoring and Analytics

Data.

It's the lifeblood of good software. It will tell you what works, when it works, how it works, and who is using what in your app.

So you need a tool in place that efficiently collects and collates data to help you make smarter decisions about your app and how development will proceed in the future.

What do monitoring and analytics tools provide?

They are data filters – they show what works, what doesn't, and how people are using your app. They help you:

• Understand Your Users and Where They Are from – Good analytics will break down user characteristics into great detail, showing you where people are from, what their buying habits are in other apps that are tracked, and other basic demographic details that can help you build a better app and drive new users in the future.
• Measure Actions Taken In-App – What do people actually do when using your app? Are they using the core features? Checking out something else you included? Getting stuck on certain screens or in a navigation loop? The data will help visualize these paths and how they take actions in your software.
• Payments and Revenue In-App – While your app probably won't have in-app purchases right away, future updates can benefit from this kind of reporting. Know what people are buying and why they decide to buy it based on their behavior in the software.
• Reporting Based on Your Business Goals – You have goals and will have new ones specific to your business. With analytics and monitoring installed, you can track performance and see if you are anywhere near reaching them.

Can you imagine building additional tools for your app without this kind of data? What would be the point?

Dave McLure, Super Angel Investor and founder of 500 Startups, even has an acronym to help us:

• Acquisition – Where/what channels do users come from?
• Activation – What % have a "happy" initial experience?
• Retention – Do they come back & revisit over time?
• Referral – Do they like it enough to tell their friends?
• Revenue – Can you monetize this behavior?

Or "AARRR!" for short – referenced appropriately as the "Pirate" metrics.

Specifically, for a first time developer and a brand new app, there are a few things you're going to learn from this data right off the bat:

• Which Features Matter – Right now, you have a laundry list of new features you may consider adding in the future. Good data can help you make decisions on which ones make the most sense to develop first.
• Where Problems Occur – Good data will help you determine where problems are most likely to happen in your app. Whether it's a frequent crash, a broken menu item, or just a very frustrating component of the software, this will help you get a picture than direct complaints, which often only represent a fraction of the issues that occur.
• How to Run Ad Campaigns – If you use analytics that tie into ad programs like Google's, you can use the data from your app to make decisions about how best to spend your ad budget (if you have one).

That information is going to guide you in the next steps when this book is completed. When you've launched your app, run it past your first few users, and created a system through which you can collect and analyze data, this stuff is going to be pure gold.

It's going to help you get more done, see what works and what doesn't, and ultimately create a better, more powerful app.

To get started, there are a number of tools that plug right into your app without any additional coding needed. Here are some of the best:

• Flurry Analytics – This is in the Yahoo Mobile Developer Suite (YMDS) and has a ton of useful data that can be shown on their classic dashboard or one of 10 custom dashboards you can build. You'll get usage data, audience information, technical data, and events.
• Google Analytics – Yup, Google has an app for this too. Surprisingly, though, Google's mobile apps analytics tool has only been around for 3 years and only out of beta for about a year. The cool, thing though, is that it's part of their Universal Analytics suite – meaning it combines data from all sources using the same user ID in Google Analytics. If someone views your website on a desktop, then downloads an app to their phone, then uses that app before going back to your website to read more about it, Google captures everything and pulls it all together. The big downside here is that you don't get iOS data for conversions in the App Store if you're building for iOS. It's probably the most powerful, but again, this is Google and you're giving them a lot of data from your business.
• Apple App Analytics – While very cool and integrated with iTunes Connect, this one doesn't offer enough data to be the only analytics tool you use. You'll get stuff like App Store Data, Sales Data and Usage Data, but the latter is pretty thin. This is a good one to pair with Google if you're launching on iOS.

While the largest, these aren't the only ones out there, either. Here are some others you may consider, depending on your feelings about the above companies:

• Facebook Mobile Analytics – Great if you plan on promoting your software on Facebook heavily. The integration here is deep, which is both good and bad depending on how much you want to rely on Facebook.
• MixPanel – Works for iOS and Android, this one is freemium so you get limited data points in the free version. That said, the actual data is solid and it can be tied together with web data.
• Answers by Fabric – This is a great platform with a lot of functionality and a fun UI, but it's owned by Twitter, so know that you're tying yourself to their platform and what makes the most sense for Twitter in the data.
• Countly – This is a great one because it offers the power of so many others, works for iOS, Android, and Windows Phone, and is very easy to use. The best part? It's free if you self-host – one of the only open source options with this much functionality.

As you can see, there are a lot of options out there – pick the one that best fits your needs and technical savvy.

Gathering Feedback through Your App

One of the most effective ways to get early feedback on your app is to build something into the interface to solicit feedback.

You've seen this before. A pop up or light box that appears and asks you to leave a review, write a comment, or submit a report if there is an error in the app.

This stuff is absolutely vital because it gets real feedback from actual users while they are using your app. There's no other way to do this unless you're looking over their shoulder.

Fortunately, you don't need to get nearly as fancy as the big guys do with your feedback request.

Complex submission systems and contact forms within the app aren't necessary – all you really need is an email address that someone can tap or click on when they have questions or concerns…and a reminder of when to use it.

For your earliest users, this options should be as big and bold as possible. You NEED that feedback because it's going to drive development on your project through every iteration for a long time.

Error Log

Finally, there's your error log. When something doesn't go off as planned in the app, the software should log it.

This helps in several ways.

First, you can test the app internally – running through it yourself, sending it to usability testers if you have the budget, or pestering your family to help out.

Every time something crashes or breaks, the log will catch it.

Second, if an error occurs for a user, the error log will catch it and if they choose to send it to you, that data can help you make changes.

You've probably seen the screen that pops up when Microsoft Word or Photoshop crash on you – asking if you'd be willing to send the error report to the developer.

This is a relatively simple integration and the data you collect from it is gold.

What to Exclude from Your Prototype

Now that we've established what needs to be there (not much), let's look at all the stuff you should wait on for now.

Keep in mind that everything on this list is temporary. If your app is a success, you can add features to your heart's content, creating a bigger, better, more attractive app over time.

But for now, that stuff is a distraction. For every new feature, you're looking at hours and hours of your time, and hundreds more potential bugs that you'll have to sift through.

It delays the launch of your app, makes it run worse, and waters down the experience of the core functions. In short, you can sabotage yourself by getting greedy this early.

On the plus side, having a clear list in place and an idea of what you will add and when allows you to build a roadmap for the future – a sort of next steps guide that you can not only use to drive development but inform your user base.

So what exactly should you leave out?

The easy answer is "pretty much everything", but more specifically, the following things should be put on hold for as long as possible as you launch your app:

• The Backend – Server-side functionality is expensive. Not only does it mean monthly fees – money out of your pocket before you even launch – but it creates more points of failure for your app. Even if a robust backend is in the plans, try to build the prototype without it. If you can launch something simple and self-contained, you'll have an easier time getting up and running long-term.
• Bells and Whistles – What's a bell and/or whistle? Simple, this is the stuff to which you think "that would be so cool!" If you think this, it's probably not needed. Design elements beyond the basics, fancy submission forms, secondary functions, expensive stock video or graphics – none of this is needed to make your app work.
• Non-Core Features – You'll have a long list of possible features you want to include in your app. But not all of them need to be there. More likely than not you only need one or two of them from your list to get a prototype out the door. Everything else is considered "non-core". Put them on hold for now.
• Unique Ways to Do Things – If you can use an existing tool to do something, do it. Don't reinvent the wheel just because you thought of a unique or cool way to do it. Later.
• "Smart" Features – Smart functions are awesome – they remember the user, customize the layout and navigation to match their needs, and can automate a lot of what software does. It's also time consuming and bug-ridden. Wait on this for now.

The bottom line, and I cannot emphasize this enough, is that your app doesn't need to be a revolutionary, mind blowing production with every bell and whistle you can think of – it just needs to work. It needs to do one thing and do it well.

If you nail this, the rest will fall into place.

So don't get carried away.

Who Is Building Your Software?

When I first started writing this book, this section was going to discuss in great detail how to hire a programmer for your project.

But realistically, that's a nightmare waiting to happen.

There are situations in which this makes sense. If you know what you're doing, it's the fastest way to get things done, but for those new to the field, it's costly and potentially dangerous to invest in someone you don't even know to build your product.

The world of freelance development is riddled with scam artists and lazy contractors who may or may not get it done on time (or at all).

I don't say this to scare you (as there are a lot of very good contractors out there as well), as much as to remind you that there is no "easy" path to getting this done.

For someone in your shoes there are really only two paths to getting your first app completed:

1. Bring on a technical cofounder who can build it
2. Take a break and learn how to do it yourself

How do you determine which makes more sense to you? Let's take a look at your options – all three and which applies best to you.

Cofounder:

• You are driven, ready to move forward, but unfamiliar with the technical aspects and have no money to invest.

Do It Yourself:

• You have a basic knowledge of programming or are eager to learn, the time in which to learn, and have limited your prototype to the bare basics.

Hiring a Programmer

• You have a basic understanding of the code and resources needed to develop software but not necessarily the time in which to do it or learn how to do it, and you have money with which to hire someone.

For Those That Hire

If you do opt to hire someone to develop your app for you, there are quite a few options out there.

They include:

• Hire someone local that you know
• Use Upwork or Freelancer.com
• Go to programming-language-specific job boards
• Talk to a friend or family member

There are pros and cons of each of these methods, and as you'll see shortly, a lot of things that can trip you up. I only share this with you to make sure you know all of the potential outcomes of hiring someone on the outside to handle development of your project.

It certainly can go well; it can also fall apart and turn into a massive headache almost immediately if you are not careful.

What to Look for in a Developer

Hiring a developer is like hiring a mechanic for your car – they're doing something you don't fully understand and could easily lie to you if they so choose. You need someone who is honest, skilled, and organized.

How do you know if they are any of those things?

It's not easy. A mechanic is hard enough, and you meet them in person. With a developer online, you only get their emails, and there is no guarantee that English is their first language.

Here are three things you can do, though, to help weed out the liars and ensure you find the right person for your project:

Red Flags to Watch For

People lie for plenty of reasons – whether to hide past failures or to make themselves look better. Here are some red flags to look for that could indicate a lying contractor:

• Has No References – Or won't provide them. Anyone doing business online should have a laundry list of past projects to show you. If they're new to the game, ask for professional references and a resume or CV.
• Wants Upfront Payment – Asking for a deposit on a large project is perfectly normal, but asking for a big chunk of cash up front when you've never worked from someone, especially if you're using a site like Upwork where the hours are guaranteed – that's a different matter altogether.
• Refuses to Provide Numbers in Writing – This goes without saying. If someone won't commit to paper and a signature on their quote, they aren't confident they can get it done.
• Provides Few Details on the Process – Ask someone what their work process is. If they do this professionally, the description should be long and detailed. If they can't provide it or refuse to do so, they may not know as much as they claim.
• Poor Communication – If someone misses one email by a day or two, it could be a mistake or a timing issue. If they repeatedly wait to respond to your messages for 24-48 hours, ignore questions, or seem to misunderstand much of what you're asking, that's a much bigger red flag.
• Doesn't Seem Interested in You – Some contractors are in it for the volume. They pull in as many contracts as they can and complete them whenever they feel like it, or worse, subcontract it to someone else. If they aren't asking you questions, refuse to talk on the phone, and offer few ideas or suggestions to improve or streamline development, they probably don't care that much.

The bottom line is that if you feel funny hiring someone, they're probably not worth hiring. Always keep this mind.

Test People Before Hiring

Before you agree to give anyone money, test them. Ask them a few select questions that they should know the answer to if they are telling the truth about their background. These might include:

• How many other projects do you have? – If you're their first, reconsider. Yes, you can get a killer deal on a freelancer who is just getting started and knows their stuff, but it's a bit of a crap shoot.
• How many projects have you worked on? Any like mine? – Don't just ask for a portfolio, ask for similar projects – at least in terms of the coding and deliverable.
• What are your regular work hours? Do you have a full time job? – Find out if this is a side gig or a full time job. The latter can be fine, but don't expect your project to be top priority if so.
• Will anyone else be working on my project? – Always ask if they plan on subcontracting any part of the project. You want to know who is building your software.
• When can I expect to hear from you? – Pretty simple question and yet many contractors won't have a good answer. Set clear communication guidelines and expectations.
• What tools and software will you use in development? – They should know the answer to this without even stopping to think. If they have to think, they're not ready to work with you.

Don't be afraid to get more technical and ask intentionally tough questions that an amateur wouldn't know how to answer.

Don’t Trust Any One Thing

It's easy to get sucked in by a glowing review or a strong interview on the phone. Be sure to take into account ALL of the things you see related to a candidate before hiring them. These include:

• Reviews
• Portfolio
• Profiles
• Social Accounts

If you see a red flag on ANY of these, walk away. Don't try to make excuses or ignore the reality of the situation – just walk away and you'll probably save yourself a boat load of both money and time.

As you can imagine, hiring someone is a stressful experience. You're putting all of the work we've done in this book into the hands of someone else – someone you don't know and you are trusting to tell the truth.

If they are lying or worse, if they are lazy and don't feel like following through on what they've promised, you're out a bunch of time and possibly money.

For this reason, I do generally recommend you build it yourself. You save money, have full control over the process and can make changes as needed. If the knowledge is there or you have the drive to develop that knowledge, do it yourself.

Defining the Timeline and Scope of a Project

Regardless of who is building your software you need a plan in place for the size of the project and when it is going to be completed.

A good prototype in general should be something you and a team can complete in a weekend.

Yup, just 1-2 days to build out everything needed to have a working app based on your sketches and outlines.

This is incredibly cool. Gone are the days when the mere thought of developing software was a multi-month or even multi-year possibility. If you can really keep the scope narrow, avoid overdoing it on the excess features, and get something together quickly, you'll be able to keep it as simple as possible without any potential issues.

At the same time, be realistic.

If you have a part time job on the weekend, schoolwork is overwhelming, or if you are truly doing this 100% on your own, 1-2 days may be a bit overzealous. In these situations, you may want to consider a smaller scope or a longer time frame.

And one more general rule of thumb here that applies to just about anyone, including yourself.

Whatever time frame you set – whether it's for you, your cofounder, or a developer you hire – double it.

Development is a messy process and things will crop up. Whether it's life or a bug you can't get around, you'll almost certainly find yourself fighting the deadline at some point – tack on a few extra hours or days if needed to make sure this doesn't become a problem.

The Build Process

Once you have it scoped out, outlined, timelines and budgets set – what does the actual process look like?

There are several things to keep in mind, and again, it will depend a lot on whether you do this yourself or hire someone to tackle it for you.

The Flow of Information

Whoever is building your app will need a lot of information. They will need to know just about everything you've done thus far in the preparation and development process, but probably not all at once.

If this is a cofounder you're working with closely, they should be in a good place right now and feel comfortable building without too much input, unless you brought them in towards the end of the research and outlining stages.

If this is a contractor, you have to assume they know nothing. Never assume, even if you're hiring someone with extensive experience, that they know everything there is to know about your app and how you are developing it. Give them the benefit of the doubt to be sure, but also feed them everything they need as actively as possible.

How Many Iterations in Prototyping?

Is your prototype the first thing you build?

To some degree yes, but keep in mind that development is an ongoing process. As you work on the project, things will break, bugs will appear, and others just won't work. Those can be fixed on the fly, but the goal here is to create a working prototype, not a perfect one.

If you can open it, use the core functions, and close it without a crash or major bug, you have a successful prototype.

Many iterations might be needed to reach that point, but ideally you're looking at a couple days to get something workable together.

When Is It Ready to Move On?

When it works.

Realistically, this won't take long. If you're keeping it simple and not reinventing the Internet to make it work, you should be able to cobble together the tools and new code needed to run your app in 1-2 days.

And as soon as it works without crashing, it's ready to move on. That might be the same day you start or it might take a week. This will almost completely depend on who is building it, how complicated your specs are, and how much of a perfectionist you decide to be.

When to Worry

There are going to be problems. Every build has them. Whether it's an AWOL developer, a bored cofounder, or a gap in your knowledge that slows down the development process, don't expect it to be one smooth run from start to finish.

There are going to be problems along the way. That said, there are some red flags you should watch for that could indicate a larger problem that needs to be addressed.

• Fixes are creating new problems on an ongoing basis – It's pretty normal for a fix to create a new bug. Heck, half the time you'll end up fixing the same problem several times as you work through issues, but if it becomes extensive to the point that you're spending days on the project, there may be a bigger problem at play.
• The developer is getting frustrated and downgrading priority on the project – If it's a contractor, dig into them because you're paying them for their work. If it's you or a cofounder, it's time to talk – losing motivation this early in a project can be tough, but you need to power through. You're 80% of the way there – why quit now?
• Your own use of the software is disappointing – If you use an early build and find it disappointing or frustrating, chances are that early users will feel the same. Don't let a perfectionist's goggles delay launch, but don't feel crappy about a product you'll be putting your name on either.

For most problems, the best solution is to power through and just get stuff done. But when the problem promises to derail your efforts, slow them down significantly, or just piss you off to the point that you want to quit, take a step back and re-evaluate. Is something bigger wrong?

What to Do When You Get Something Back

The prototype is done. You've used it. You don't hate it.

Ready to launch, right?

Not quite. A good prototype is the first thing you'll use to get feedback, but that doesn't mean it's necessarily ready to sell. There are more steps that you should take, many of which we'll cover in the next chapter.

The QA process, checking for any app-breaking errors, is probably the most important of them all. Sure, you need to figure out how you are going to package and sell this thing, but if it won't run when sold, not only will it fail, you'll waste a lot of time.

Don't skip this part. It's incredibly important and is going to give you the insights needed to really ensure your app is ready for the prime time when it goes out.

Go to ruwix to learn the solution of the Rubik's Cube and other twisty puzzles like Pyraminx, Skewb and many more.