You're the Brains and They're the Brawn

How to Hire Great Programmers

“Wait, wait wait. How do you expect to create an app if you're not a programmer?” His words pierced through my superficial layers of confidence and left me feeling confused, speechless, and wondering the same thing.

I responded with a quick, defensive, “Hire someone, of course.”

Without a skip of a beat he immediately followed with, “Okay. Well, how do you find those people?”

Again my answer was less than smooth. I remember becoming frustrated and wishing I hadn't bragged about my million-dollar app idea in the waiting room of my doctor's office to an 88-year-old man who didn't even know what an iPhone was. Nevertheless, he was right, and I didn't have the slightest clue what I was talking about. I figured there had to be a way, and I was going to turn over every rock I could to find the answer.

Later that day, I boarded a plane back to Vermont to continue my recovery at my family's house. Fueled by my frustrations with the conversation earlier in the day, I bought a fresh copy of Macworld, a magazine about all things Apple, hoping to gain some insight about apps. I started flipping through it and landed on a quarter page ad that read “TURN YOUR APP IDEA INTO $$$.” It was an ad from a software development company that was offering iPhone app development services. Jackpot. I will show you, you cynical waiting room critic, I thought to myself.

Meanwhile, as I was taking in every bit of information the ad had to offer, the pilot had started his “Ladies and gentleman, blah blah, thank you for flying with us, blah blah” spiel. When I was done with the ad and looked up full of excitement, he was completing his announcement, with “Sit back, relax, and enjoy the ride.” Little did I know that his words were not only meant for that plane ride but also for my app adventure, which was about to take off.

A few days later, I found out that the development company in the magazine was located only two hours away from where I was staying in Vermont. At the time, I still had the old-school real estate mentality that business had to be done in person. So, I decided to take a trip down to have a face-to-face meeting with them.

“Nice to meet you,” John, the owner, said as I shook hands with him and the team. Their eyes were glued on me, which made me feel completely out of place. Maybe this wasn't a good idea, I thought to myself. My inner Negative Nancy was chiming in. I awkwardly sat down at their board-room table, and started telling them my idea and how I knew nothing about this new world of apps but that I was eager to learn.

“No worries. We will help you out,” said Kevin, the project manager. After a few minutes discussing how the app would work, how long it would take, and how much it would cost, my uneasiness drifted away and I began to feel more confident.

I left the office that sunny Friday afternoon with my head held high and a swagger in my step. Talking to them had given me clarity and removed many of the hurdles I had seen before me. That's when I understood the importance of what development companies do and the value they can bring to an app business. Suddenly I believed almost anything was possible in the app world. My brain opened up and my thoughts turned into an uncontrollable creative avalanche. The possibilities seemed endless. “Okay, we can do this, and we can do that.” I started coming up with all kinds of ideas and I actually had the people to execute them. Problem solved. Next.

As an appreneur, it's easy to hit a barrier because you may not know if the technology will support your app ideas. The great thing about programmers is they can give you answers. Instead of blocking your creativity, hire the right people and be resourceful. I lucked out with my first development team, and then through multiple experiences, some good and some bad, I learned how to hire good people. In this chapter, you will learn how to find, hire, manage, and fire developers and to set up systems that will help you turn your possibilities into realities.

THE IMPORTANCE OF PROGRAMMERS

As of this chapter, you have been researching the market on a regular basis and have used the last chapter to create up to three well thought-out app ideas. Now what? If you are a programmer or are technically inclined you might think “Cool, I can write my own apps” or “I'll teach myself how to code an app.” You might get a few books on how to program and start writing code at crazy hours of the night hooked up to an IV full of coffee.

Well, you could do that but I would highly advise against it. It's important that you keep your momentum and get an app out to the market as soon as possible. Coding your own app, especially if you're teaching yourself at the same time, will take too long. The likelihood of you getting stuck and giving up is very high.

This model will also be unsustainable over the long run when you want to create several apps at the same time and consistently update your existing apps. After all, the idea is to get your time back and escape the long hours of the rat race.

Another reason to outsource app development is that you have to focus on the role of a businessowner. This means having a bird's-eye view of key aspects of your business like market research, marketing, networking, and so on. You won't be able to do that if you're spending all your time in the trenches. You don't see Donald Trump running around with a hard hat on the 40th floor of his new skyscraper and hammering in nails do you?

You must decide that you will focus on the high-level operations of your company rather than getting lost in executing minute details. Programmers will be the foundation of your business and allow you to create apps quickly and scale easily, which will allow you to remain the captain of your ship.

WHAT TO LOOK FOR IN PROGRAMMERS

Since programmers play such a vital role in your business, you must be particularly discerning when it comes to selecting them. Just as you wouldn't let anyone build your dream home, you need to use care with who is laying the virtual bricks of your mobile empire.

When it comes to selecting programmers, you have to focus on certain key areas. These include experience, communication, team, pricing, and conflict of interest.

Experience

The first thing you need to assess is the programmer's level of experience. It's not a good idea to work with programmers who haven't worked on many apps. Sometimes when programmers are beginning, they will offer cheap rates. This is like taking a helicopter ride with a pilot who has only flown a few times. I wouldn't recommend it.

One of the first things I ask to see when considering new programmers is the apps they have created. If a picture speaks a thousand words, to me, an app speaks 10 thousand. Download the programmers' apps and assess the quality of the work. Does it look sharp and work flawlessly, or is it clumsy? Does it look professional or substandard?

Sometimes they are bound by nondisclosure agreements (NDAs) and are not able to disclose the apps they have worked on, or they have only worked on parts of an app. Regardless of this, you have to see their products in action. If you can't, move on unless you're into buying cars without test-driving them.

The programmer's website can be a useful assessment tool. This is particularly true for development companies, which often showcase their work on their website. It should highlight some of the apps they've done and give you confidence they aren't a fly-by-night company. The quality of the website can indicate the quality of apps they create. Independent programmers don't always have a nice website, but if their portfolio of apps is impressive, you should continue assessing them.

When hiring a programmer, ask for references. Talk to at least one person who has worked with this programmer before. I prefer two or three, which can be difficult to get, but why not try? This is not as important for programmers that you find on outsourcing websites, such as oDesk (appempire.com/odesk) or Freelancer (appempire.com/freelancer). On these sites, assessing developers is easier because you can review detailed statistics on their previous work performance. You will see reviews and ratings from their previous clients and can determine if they're somebody you would want to work with.

After doing a general assessment of the programmers' skills, you need to ensure they have the specific experience necessary to complete the app. I get into this usually during a second conversation after I've done my initial assessment and had the programmer sign an NDA. You will be able to estimate the skill level when you look at the previous work, but you still have to make sure that the programmer has the specific skills your app requires.

Communication

Even though cost of development in other countries may be lower, the language barrier can be a hassle. Work with programmers who share your native language. You must be able to communicate with your developer effectively. It may cost more, but you will get higher quality work and fewer headaches. Does this mean you should never work with somebody from another country? Of course not, but just make sure they're fluent in your language.

Something else I expect from programmers is technical guidance. When I started, I was a complete novice, but I was fortunate to work with programmers who educated me about technical jargon during the entire process. Not all programmers are skilled at this even if they're good at creating applications. Make sure your first programmers are willing and able to explain things to you in non-technical terms.

As you gain experience in the field, you will need less guidance, but initially this is important. You will find out quickly if you are talking to programmers who do this inherently. They will ask you questions and often give you a crash course to help you understand the scope of the application you want to create. This is huge. Programmers should not be your only source of education, therefore rely on yourself as well to learn what is necessary for this business.

Another big one is responsiveness. You've had a peek at how fast-paced this industry is. Sometimes a delay of a week can make a difference of a few thousand dollars. You must be able to make changes on the fly, therefore you need programmers who are as responsive as possible. If you're dealing with programmers who have too much on their plate, find people who can make you their priority. Keep an eye on the programmers' responsiveness at all times, especially during projects. Don't allow for any lapses, and mention problems if you see them.

By the way, this is true for yourself as well. Programmers are people like you and me, and they can get frustrated if they feel their time is wasted. If they need something from you, get it to them quickly. Be as responsive as you expect them to be. In the beginning, I was notorious for not getting my programmers what they needed and often created bottlenecks and delays.

Also, silence your inner control freak and do not be too high maintenance. You have to stay on top of things but excessive communication will slow down and possibly frustrate the programmers. I usually ask them how often they like to talk about the project. Come up with a schedule that accommodates both of you and stick to it.

Another important step is being cautious of working with programmers in different time zones. Keep the time difference to a minimum because it can become a major hiccup in communication. Maintaining the momentum of your business will be difficult if by the time you get up in the morning your programmer has hit stage three of his sleep cycle.

One of the most brilliant programmers I've worked with before lives in Germany, and whenever I'm on the West Coast, the nine-hour difference makes it almost impossible for us to work together. When he closes shop at 5 p.m., it's 8 a.m. here. Of course, he can make exceptions at times, but this is unsustainable. Some outsourcing companies rearrange their employees' workday to match it to the U.S. workday, but if you don't have at least a three- to four-hour window of shared time, find someone else.

Team

Whenever possible, work with a team rather than an individual especially in the beginning. This has several advantages. Teams can be more reliable since they can pick up the slack if the programmer working on your project gets sick or becomes unavailable. This is a big one as you can imagine. Ensure that not everything rests on one person's shoulders especially as your projects become more complex.

A bigger team can get things done faster. App development can't always be evenly distributed among a set number of people, but a skilled team will know how to get things done faster without losing track of the overall project.

The biggest reason for using a team is that a team will include graphics designers and sometimes project managers. You can have the best code in the world, but if your graphics look bad, people will be less likely to give your app a chance. The ideal situation would be to have a programmer who can code and create the graphics. This is rare, so the second-best option is having programmers and graphic designers working in tandem, like a well-oiled machine. You will also use graphics to market your apps, so having a graphic designer who can create killer marketing materials is a must.

One more benefit of working with a team is the variety in the programmers' skill sets. Initially you will want to have the right talent for your first app. But as you create a greater variety of apps, you might reach the limits of a programmer's abilities. Your programmer should be able to reach out to his team members or his professional network for assistance.

These are guidelines and not strict rules. As you gain more experience, special circumstances may warrant using a programmer who does not work with a team or have graphics capabilities but has a specific skill set that you need. Keep this to a minimum because it's easier and less risky to have everything under one roof.

Pricing

You can expect a wide range of prices and services since many companies and independent developers compete for your business. Projects can be billed at a fixed cost or hourly rate.

Start with contractors who offer a flat fee, with a certain number of free refinements (called iterations). I rarely develop apps on an hourly rate because I feel programmers don't have an incentive to finish fast. I want them to feel the same sense of urgency that I do when it comes to developing apps. Being on an hourly rate has the opposite effect. This is not true for all developers, but this strategy has served me well and has become my preference based on my experiences. If people have done some quality work for you in the past, and they prefer hourly rates, that might be the way to go for you.

Another advantage of fixed-rate projects is that it'll be much easier to stay within your budget if you know how much the work will cost. You want to get as many apps to the market as possible with your initial budget. Going for fixed-rate projects might mean the difference between creating two apps versus one.

You might ask, “How do I know that I'm getting a fair quote for my app?” Typically, companies are going to charge more because they have more overhead than individual programmers. You can avoid overpaying by getting quotes from three different developers for each one of your ideas. Discrepancies will exist between the prices, and as you figure out why, you will learn a tremendous amount about the programmers and about your app. Don't be afraid to tell programmers you prefer that you have other quotes that are lower than theirs (only if this is true, of course). They might match it. Business 101.

As for payment, you should never pay upfront in full. Avoid a down payment if you can, but if you can't, ask the programmer to provide clear milestones and prices for each of them. Don't release a payment until you're confident the requirements of the milestone have been met. The nice thing about sites like oDesk and Freelancer is that they mitigate the payment process by acting as an escrow service and providing a payment system that corollates with the milestones.

Be cautious about using royalty agreements when it comes to paying for apps. Some developers will lower their development cost if they receive a cut of the app's income (called royalties). It's easy to think, “Oh, giving up 10 or 20 percent is not a big deal.” You might save money or the programmers may do a better job if they are vested, but these advantages are negligible to the potential disadvantages of a royalty deal.

A royalty deal essentially makes the programmers your business partner, which can get messy. What if you want changes to the app they disagree with? Or what if they interfere with your marketing efforts? What happens if you have an opportunity to sell the app or your company? An app can be a long-term asset and giving up a piece of it can take away a lot of money. Keeping track of royalty payments can be cumbersome as well.

Conflict of Interest

Sometimes programmers create their own apps and publish them on the App Store. Their hope is they might strike gold, but in the mean-time, they will make extra cash by developing apps for others. These will mostly be independent developers, but some development companies do this as well.

Strictly speaking, this is a conflict of interest because your competition is creating your products. This is so prevalent in the industry that you probably won't be able to avoid it. Just be protected as much as possible by showing the programmers your awareness of this and have them sign NDAs and possibly app-specific non-compete agreements. But don't let this prevent you from moving forward.

FINDING AND SELECTING PROGRAMMERS

When I started my company in early 2009, the industry was so new that it was hard to find quality programmers. Because of the worldwide app craze, you can now find them more easily. Many software development companies now focus on app development. Quite a few independent programmers have appeared all over the place.

For my first few apps, I found it much easier to work with a well-known company that could hold my hand before diving in with independent programmers. This was a good starting point because the company was versed in working with inexperienced clients. I recommend you go the same route because bigger companies have more experience with educating people who are wet behind the ears. This will help you accelerate your learning the basics of app development and teach you how to communicate with programmers. Working with this company gave me the confidence and momentum I needed to continue to forge ahead in the app business.

How do you look for programmers? Well, you have many ways to look for programmers such as a simple Google search, job sites like Monster, Craigslist, app conferences, meet-up groups, programmer forums, word of mouth, and outsourcing sites (such as oDesk and Freelancer). Some of these methods are easier than others, but no magic formula exists. You'll have to use various sources and assess multiple programmers until you find several who you're comfortable pulling the trigger with.

Your approach will basically be the same with each programmer or company you're assessing. Once you have programmers on the phone or on Skype, interview them until you're comfortable with moving to the quoting step. This is a job interview, and you're the boss. Here is my question checklist:

• How long have you been developing apps?
• How many apps have you worked on?
• Can I see the apps you've worked on?
• Do you have a website? What is it?
• Do you have references I can talk to?
• Whats your schedule like? How soon can you start?
• How long will it take to get a quote?
• What's our time difference? (if they are in a different time zone)
• What time do you usually work? What are your hours?
• What's frustrating for you when working with clients?
• Are you working with a team? What are their skills?
• Can you create graphics, or do you have somebody who can?
• Can I see examples of the graphics work?
• What happens if you become sick during a project?
• What if you hit a technical hurdle during the project? Do you have other team members or a network of programmers who can help you?
• Can you provide flat-fee quotes?
• What's your payment schedule?
• Can you create milestones tied to payments?
• Do you publish your own apps on the App Store?
• How do you ensure that you don't compete with your clients?
• How do you submit an app to the App Store? (Can they walk you through, or do they make you feel brain challenged?)

This list will change based on whom you're talking to. An established development company will most likely have a team of developers and graphics people on staff but you must get answers to the above questions before moving forward. Also, you don't need to sound like a drill sergeant or ask silly interview questions. The questions listed above are important, and they shouldn't make the person you're talking to defensive if you ask them in a friendly tone. I always have this question list in front of me during an interview and take notes as I get the responses. I've found that, in business conversations, it's good to throw some personality in there and have a little fun. Keep this in mind when you're asking your questions.

During the conversation, pay attention to how well they were able to explain themselves. Were they articulate? Did they use too much techno babble? Did they actually speak the same language? Did they seem confident with their answers? How was their tone and demeanor? If you had any issues or worries, you may want to move on to somebody else. If you can communicate with them and your gut is telling you yes, you'll want to move to the next step.

In either case, thank them for their time and mention that you will follow with an NDA agreement if you decide to move forward. Don't give away your ideas during this initial conversation. Whenever the topic comes up, say you'll be more than happy to discuss everything after they sign the NDA. You must protect your ideas, source code, and any other intellectual property because these are your assets.

Be careful with the people who handle your code as well. As your business grows, you will not only be creating new apps but also maintaining your existing ones. This means you'll have to give your code to whoever has to make changes to it. Only do this after you have established a certain level of trust. This is especially true with your popular apps.

Once the NDA is in place, it's time to dive in and ensure the developers have the skill to complete your app. You do not have any wiggle room here, especially for your first app. Either they know how to do it or they don't. You want to hear things like, “I know exactly how to do that” or “I've done similar apps, so it will not be a problem.” You don't want to hear things like, “I should be able to do that, but I have to research a few things” or “I'm not sure but I can probably figure it out.” If you hear those words, move to an app they are confident about or run for the hills.

For example, let's say you're developing a new app with sophisticated audio requirements. You could find great programmers who have done lots of apps, but they would be a bad choice if they have never worked with audio before. Use them for their expertise for some of your other apps and find somebody else for the audio app.

As you're going through this entire process, you will be getting feedback on their responsiveness. If it's taking too long for them to sign the NDA and to clarify things, this might indicate how slowly the development process will move.

Using outsourcing websites can be a great tool to find skilled, low-cost programmers. These websites allow programmers to bid on jobs that you post. As you can imagine, the competition creates a bidding frenzy that gives you a good chance of getting quality work at a low price. Following are three of the top outsourcing sites (see Figure 5.1):

1. oDesk (appempire.com/odesk)—Its work diary feature tracks the hours your programmer is working for you and takes screenshots of the programmer's desktop at certain time intervals. You can review these images to know the programmer was working on your project and not participating in his local dodgeball championship.
2. Freelancer (appempire.com/freelancer)—This site has the most programmers listed. They claim that twice as many programmers will respond to your ad, and I found this to be mostly true.
3. Guru/Elance (appempire.com/guru - appempire.com/elance)—These sites have large lists of programmers, and it's always good to have different pools of talent competing for your business.

Here are the advantages and disadvantages of these sites.

Advantages:

• Lots of programmers—These sites have large databases of programmers competing for your project.
• Fast responses—You often get bids within an hour or two of your posting.

FIGURE 5.1 Screenshots of Elance, oDesk, and freelancer.

• Skill and work history—Programmers have profiles that list their skills. You can review the previous projects they have worked on. With this information, you can evaluate if they have the specific skills for your app.
• Performance rating and reviews—Clients can rate and review the programmer. You'll know if it's worth spending more time assessing the person.
• Price comparison—Before posting your job, you can review active and closed job listings of others to get an idea for what others have paid for apps similar to yours.
• Escrow services—Your funds are protected and you only release them at certain milestones if you're happy with the work.

Disadvantages:

• Communication—Most of these programmers are overseas. This can present issues with communication and time zone differences, so a Skype interview is an absolute must before you continue.
• Protecting your idea—Because these sites are public bidding grounds, your ideas can get hijacked. When posting a job, never post your idea or marketing plan. Use general descriptions until you have an NDA.

Here are five pointers on posting a job on oDesk and assessing the responses. The process is similar on the other sites. Your ad should cast a wide net to attract as many applicants as possible. You can filter later.

1. Enter the skill requirements—What programming languages do they know? Odesk and Freelancer allow you to list up to five. This way only programmers with those skills will receive your job post. For iPhone apps, the skills I use are iPhone, Objective C, Cocoa, and C Programming.
2. Give a basic description of your project—Keep it simple and skill-specific. Tell the applicants that you will discuss details during the selection process.
3. Post your ad only for a few days—This way programmers have a sense of urgency to quickly bid on your job.
4. Filter applicants—I always filter applicants using these criteria:
   • They have a rating of four or five stars.
   • They have at least 100 hours of work logged.
   • Their English is good.
5. Compose a message to all suitable applicants—This message invites the applicant to a Skype call for further screening. Disqualify anyone who is not willing to jump a Skype call.

As you interview more programmers (regardless of where you find them) you'll get skilled at finding the talented ones. Even if a programmer passes all your tests, trust your gut because it's usually right.

HOW TO CONVEY YOUR IDEA

When I began working with programmers, I would explain to them what kind of app I wanted and how it should work. I thought I was being clear and was surprised when I received products that weren't close to my vision. It would take several iterations and a lot of time and frustration to fix things. I was even getting upset at the programmers at times, but it turned out it wasn't their fault. It was mine. I wasn't communicating accurately and was making the process frustrating for both of us. Once I realized what the problem was, everything changed. Projects were completed much faster and everybody was happier.

To convey my idea properly, I draw it on a piece of paper. Maybe it will look like a three-year-old's artwork, but it will still convey what you're trying to do. Some people like putting this together in digital form on their computer. Whatever you're most comfortable with and whatever gives the programmers the details they need is the way to go.

To make things easier, I look at certain apps in the App Store, and reference them to more accurately show my programmers what I'm looking for. For example, I'll say, “Download the XYZ app. I want the ABC functionality to work like theirs. Take a look at the screenshots from this other app, and change this.” I take certain components of apps that I'd like to emulate, and give them to the programmer so that we are as clear as possible.

The clearer you are, the fewer misunderstandings and problems you will have. The idea is to convey what the app will look like, where everything will be placed, and what happens if certain buttons are selected. This helps the programmer know what you want and is a useful tool when designing your app. Do not be vague or ambiguous. You should know what every part of your app will do. If you don't, you need to develop your idea more thoroughly. The programmer will be unable to deliver what you want if you are uncertain what that is.

When I send the sketch to the programmer, I arrange a meeting over Skype. My sketch usually is as detailed as possible but inevitably the programmer has questions or points out flaws or technical hurdles. We talk it out, and we ensure we understand how every screen, button, and feature is going to work and look. This can take several iterations before we get it right. Programmers shouldn't write a single line of code until the design is finalized.

This is part of figuring out the app's complexity and functionality. As programmers quote different features, they often give you new ideas that can improve your apps. You don't want to add too many extra features in the beginning due to cost and time but you never know when you might get a free gold nugget worth including. Sometimes you will find your idea is impossible and can move on without wasting too much time.

You have to consider the design to be final once the coding begins. You will have ideas for additional features as you start testing the initial versions of your app. Changing things after some work has been done can frustrate a programmer. It's like telling your builder who has installed your fireplace that you want it on the other side of the living room. That will not go over too well. Most people don't realize this is what they are demanding of their programmer when they ask for major changes. That's why you should take your time planning the app during the design and why the quoting process is important.

On the other hand, you can't anticipate every question that may arise during development, and you may have to change your design. This is normal and programmers expect this to a certain degree. Nonetheless, don't make major changes that negate days or weeks of work and put your team on edge.

If you keep adding features, you might unnecessarily increase costs and production time. You need to get the app to the market quickly and in a basic form to test the market. Only redesign during coding if you feel you have a good justification for this. Otherwise, add the idea to your update list and move forward with the development. I have an update list for each app and refer back to it when I want to make additions to one of my apps.

When I use this design process, many times the first version of an app is about 90 percent of the final, and we need only one or two more iterations to finalize the work. Depending on your experience, your initial layouts will probably not be totally on point, but as you learn the ropes and get a couple of apps under your belt, you will be able to create clearer designs.

The best part is the programmers can give me accurate quotes if they understand the scope of the project. This will help you, especially when you're getting started and you're on a tight budget.

TESTING HIRED PROGRAMMERS

Now it's time to get quotes and test the candidates. I recommend going to three different programmers to get quotes for each one of your three ideas. Most people think they have to invest a lot of money to create a hit app. To give you an idea of my initial start-up costs with my first app, I paid the developer $1,800 and the return on that investment was in the six figures. Pricing will vary based on the app but, keep your initial development costs as low as possible. As you gain more experience and are making money, you can safely move up to higher cost projects.

At this point, you have found programmers, screened them, signed NDAs, conveyed your ideas, received a few quotes, and picked the ones to work with. Rather than jumping into a full-fledged project with both feet, I usually test them on something small first. I systematically ask for these three things every time I'm working with a new programmer:

1. Icon—Ask the programmer to create and deliver the icon of the app. Figure 5.2 is the picture you see when you are looking at an app on iTunes or on your phone. After you have outlined your app idea, you will probably have several ideas for icons as well. Pass these on and ask for a finished 512 × 512 iTunes Artwork version of the icon. They will know what that means.
2. Hello, World! app—Ask the programmer for a “Hello, World!” app. This will take them 10 minutes to create and is a simple app that opens up and shows a page that displays “Hello, World!” (See Figure 5.3.) Programmers will know what this is. The idea here is not to test their programming skills but to determine how they will deliver apps to you for testing. This app should include the icons so you can see how it will look on your phone.
3. App Delivery—When the programmers are ready to show you a test version of your app, they have to create something called an “ad hoc.” This ad hoc version of your app needs to be installed on your phone before you can test it. The installation process was a bit cumbersome in the past but a new service called TestFlight has simplified this process (appempire.com/testflightapp, see Figure 5.4). I ask all programmers to use this service even if they have not used it before. They will be able to figure it out, and you'll be able to install your test apps with a few touches on your phone.

FIGURE 5.2 App icons.

FIGURE 5.3 Hello, World!

FIGURE 5.4 TestFlight service.

I never spend more than a couple of hundred dollars, but this test helps me see the graphics capabilities, implementation speed, and overall work dynamic (such as communication and time zone). You want to start off on the right foot or get out quickly if you need to, and this is the best way to do it.

Mention that you like to start things off with this test during the Skype interview. Do this so programmers don't get surprised after they have provided a quote. Sometimes they're happy to get this test done without a charge but sometimes they want a small fee. In either case, be clear with this requirement and have them include it in the quote.

If you have selected your programmer and you're happy with the results of your initial test, you'll be well on your way to creating your first app. But if you're not happy with the results, don't hesitate to move on.

The process of finding programmers might take some time but this is time well spent. Don't cut any corners. This will help you avoid unnecessary delays, costs, and frustration in the future. You'll always be looking to add new talent to your team, so learning how to quickly and effectively assess programmers is an important skill to have.

HOW TO MANAGE PROGRAMMERS

It can take a lot of energy to find good programmers. The trick is to manage them properly on a daily basis to keep them happy and your business strong. These are some lessons I've learned along the way when it comes to managing programmers.

Stay on Top of What's Happening with Your Project

At some point, you might decide to hire programmers for full-time work. Until then, you will be working with companies and independent programmers who will have multiple projects running at the same time. This can lead to less than an optimal flow of information between you and programmers. They may not be as focused as they need to be with keeping you appraised of their progress. If left unchecked, this can lead to projects taking longer than they should and to a final product different from what you had in mind. You're the project manager and business owner, and it's your task to keep things on track rather than expecting the programmer to do this for you.

This is something I handled poorly early on. I was letting my developers take their time and didn't diligently check on progress. I learned to ask for milestones and timelines during the quoting process. This has allowed me to know how the app will look and function at each milestone and how long the project will take before a single line of code has been written. I periodically check in and review what's working and what still needs to be tweaked. We go back and forth like that from start to finish. Most applications go through multiple iterations during design and development, and I don't release partial payments until I'm fully satisfied with each milestone. Don't let your plane get off course for too long otherwise you could end up in Antarctica freezing your butt off.

Hire Slowly, Fire Quickly

Once you get a few apps under your belt, and things seem to be smooth with your developer or development team, you might want to consider hiring one of them for full-time work. While the flexibility of using sub-contractors as needed is great, the danger is other clients can hire them and book them solid for months.

As soon as you feel you are happy with the work of particular programmers and are making some money, lock them in. I have several guys I keep on monthly retainers. They know I am going to spend a minimum amount of dollars every month with them, and as a return, they prioritize my projects.

If you notice problems, such as lack of responsiveness or sloppy work, cut your losses quickly and fire them. If you do not, they can become a drag on your company. Like with any breakup, you should part ways amicably. It's just business, and you don't want to piss people off who handle your assets.

The best way to fire programmers is to clarify they did not meet your expectations and you want to stop work. Salvage as much of the work as possible and compensate the programmer fairly, but move on as quickly as possible and chalk it up as learning a lesson.

HOW TO TEST YOUR APPS

Congratulations. You've gone through all of the development milestones, and you've got your app back. Before you pass out the champagne glasses, you need to do a few critical things. If you were having a house built, before you signed off, you'd want everything in working order. You would check major things like the roof and plumbing all the way down to minor things like the crown molding or anything cosmetic. You need to do the same thing with your app.

To start, the app must perform as expected. Pull out your initial design document and go through every feature. Never assume that something works because it worked last time you tested the app. Test each feature every time, especially before the final release. Don't stop here because, as the creator of your own app, you know how everything should work. It makes sense to you, but it might not to others.

If you worked for a major software development company, you would have a team of well-paid engineers to poke, prod, twist, and stretch your app any which way they could. As a solo, bootstrap appreneur, you probably don't have those resources. You can, however, accomplish the same thing with a resource that all of us have: our friends and family plan. Your job is to get everyone you know, from your 75-year-old grandmother to your 12-year-old nephew to test your app.

The time you spend on testing is crucial because you will see how consumers use your product, what's easy, what they don't understand, and their patterns. They will have questions that won't occur to you because you designed the app and everything about it is obvious to you.

Hand the app to them and say something like, “Hey check this out.” Don't mention that it's your app, what it's supposed to do, or how it works. Give as little information as possible and watch them as they understand and navigate your app. This experience will be similar to the one your real user will have because you're not there to explain things to them as well. Watch them testing your app and ask yourself these questions:

1. Are they confused?
2. Are they stuck?
3. Are they complaining?
4. Are they using the app the way you intended?
5. Did they find a mistake (also called a bug) because of using the app in a different way?
6. Are they having fun?
7. Are they making suggestions for improvements? If yes, which ones?

Get them to tell about their experience with it. They will be more honest if they don't know the app is yours. Don't get offended if you hear something you don't like. This feedback is priceless. Assess each response to see if your app has a problem. Ask yourself these questions:

1. Would other users have the same issues? If yes, how can you fix it?
2. Should you move things around?
3. Should you change colors to improve visibility?
4. Would adding some instructions help?
5. Should you improve navigation?

I showed one of my latest apps to my friend, Jason. While he was testing it, he had a small problem. “Chad, it looks nice, and it seems pretty cool,” he said. “But how do I get back to the main menu?”

“Right there,” I said. “Where?” he asked. And it dawned on me. The back button was the same color as the background, and it was small. It was not registering as a button in his mind, and I realized this would be an issue for others. Those extra 10 minutes showing him the app paid off.

After you gather the feedback, have your programmers make the fixes or changes. You want to guarantee the app works on different models of iPhones, iPod Touches, and maybe iPads. Apple continues to innovate and come out with new devices every year. The more of these your app can support the better. This is something to discuss early on with your programmers. Make sure they create the app with the different devices in mind.

Again, you want to test your app on all these devices but that's impractical when you're getting started. It will be your programmers' job initially to test the app on all the different devices. I ask my programmers to create a detailed feature checklist that I look over and improve if necessary. I test each feature until everything works as expected.

Testing and debugging will take several iterations, like the design and development stages. This is all part of the process. Use the TestFlight app and service mentioned before to save lots of time with the mechanics of installing test versions of your app. At some point, you'll be wrapping up changes and sending the app off to the iTunes store for distribution.

It's a good idea to have your programmers show you or someone on your team how to submit your first few apps. Don't give out your online developer portal login information to your programmer or anybody else. The best way to do this is to use Skype or GoToMeeting and share your screen while they walk you through the process. As your business grows, you might want to delegate this work to someone on your team.

And keep in mind, all of this is much easier than it sounds. Now that you understand the importance and process of creating a development team, it's time to take things up a notch and have some fun. In the next chapter, we're going to discuss your most important job, which is marketing your apps.

What I Learned

1.

2.

3.

Actions to Take

1. Look for programmers.
2. Interview at least 10 and select the best three.
3. Create a thorough design for your app idea.
4. Get quotes from the three programmers you selected.
5. Choose one and test him.