Don’t be ashamed if you are creatively or technically challenged. Because you’ve focused on the ideas and concept of your app, you’ll be in a much better position if you need to hire or outsource its design or development. Because the app market is booming, there will be no shortage of people and companies ready to “help” you. Your job will be to separate those who are merely following the app gold rush from those who can successfully bring your concept into the App Store.
In this chapter, you’ll explore:
Skills needed to bring an app into the App Store
Your role in the development process
How to estimate costs to develop your app
Places to look for help and how to evaluate resources
Although some people reading this book have the creative or technical abilities to build an app without help, others do not; this chapter is focused on those in the second category. If you fall into this second category, you are already in a much better situation because of what you’ve been doing, including becoming a connoisseur of apps and engaging the iOS development community (part of Phase 1 of your marketing crescendo from Chapter 8). Your next step is to find those with the expertise you are lacking.
Note
If you are developing your app yourself or you already have resources to build it, you don’t necessarily need to read this entire chapter. The interviews, however, are particularly insightful, and I encourage you to read them. Also, the chapter contains some good nuggets about scheduling and where not to cut corners with your team members.
Before I start pointing you to places to look for software developers or designers—in the form of independent contractors, small app development firms, or agencies—to help you build your team, I want to equip you with three pieces of information:
The types of skills that are required to build apps
How to vet those who claim they can help you
An understanding of the costs involved to build apps
In terms of the third point, although you won’t receive any cost estimates until you begin interacting with designers or developers, it’s important to go into these conversations with the right expectations and background on the talent market.
Because building an app is fundamentally a software development effort, the same types of skills are required. I’ll break these skills down into three broad categories: product management, design, and software development.
Product management is what you’ve been doing and will continue to do throughout the remainder of your app’s existence. It entails a number of responsibilities, including strategizing, managing customer interactions, testing, and marketing. The product manager is the person who owns the product, not in the sense of legal ownership (although that could be the case), but in terms of ensuring that the app’s vision becomes its reality.
This last point is worth spending a moment to explore further. By being the visionary of your app, you will be the product (app) expert. This expertise derives from your understanding of the App Store and what you are learning from your customers. The firmer you are with the strategy and direction the app should take, the fewer questions your team members will have.
With more details, especially details that are documented (rather than just floating around in your head), you’ll have a larger pool of talent you can choose to work with and will, in most cases, reduce what it costs you to build your app. Consider the difference between giving a detailed written description of the house you’d want a builder to create for you and just loosely describing it. Even though the builder knows how to build homes, he won’t necessarily create one you like without clear input and direction from you. The same is true in the development process for your app.
More tactically, the product manager acts as a project manager, tester for quality assurance (QA), marketer, and customer support representative. These responsibilities can include scheduling meetings, taking notes, ensuring that tasks are being completed on time, keeping a team talking, writing marketing copy, rigorously testing the in-progress app, and regularly interacting with customers through all marketing and support channels. Since your other team members may have little interaction with customers (although you should do your best to directly expose the team to them), you will need to aggressively represent your customers and be a proxy for them internally.
I wrote most of this book to help you perform the functions of the product manager. So, in a sense, you can view not having to hire a product manager and executing these duties yourself as a way to save money. I do, however, want to offer you a word of caution about operating under this mindset. These responsibilities are extremely important, and if you decide to assume them, you need to consider yourself a full-time member of your team. Failing to do so can result in your app getting off-schedule, miscommunication (or no communication) among team members, and launching an app that has no real chance of success. If you have the financial resources, or if your strengths are in design or development, you should consider having an actual product manager oversee your app for you.
Note
The interviews at the end of this chapter also provide some helpful perspectives on the various roles required in developing an iPhone app.
The designer for your app will lead all its creative direction. This includes choosing the colors and fonts and creating the logo, app icon, any required artwork, and actual screens. The product manager will collaborate with the designer to ensure that these elements match the app’s vision and strategy. As the designer completes the design assets, she will give them to the developer to incorporate into the app.
Although you will want a designer with app experience, it’s good to work with designers who are comfortable with other forms of media. For example, as part of the marketing process, you’ll need to build a website. The branding aspects of your app (colors, typography, and logo) are also more general design tasks.
Great design is extremely important in the App Store. In the next chapter, you’ll also learn that great design does not focus on visuals alone.
I’ve been using the word “development” to describe the entire process of building your app and “developer” to generally refer to those involved in creating an app. The software developer, however, is the person who will actually code and program the application and drive your app’s development. Development, in this context, includes the technical architecture, programming, integration with any external data sources, and optimization for your app. I describe each of these items in detail in the next chapter. For now, it suffices for you to know that your developer is responsible for making your app functional, as well as integrating the design assets created by your designer.
Of all the roles on your team, the developer has the least leeway in terms of not having direct experience building Mac or iPhone apps. In the past, I’ve worked with designers who had not designed an iOS app and picked it up fairly quickly. But I’ve had disastrous results with people trying to learn iOS development on the fly. That’s somewhat dependent on the talent of the person you use, but let my experience be a lesson for you and go with someone who has at least basic (and demonstrable) Mac or iPhone programming knowledge.
Compared to your designer, your developer is going to be doing more work and be more heavily involved in your app’s progress, especially in the long term. Once an app is launched, unless there’s a major redesign—which does not occur very often, and sometimes does not occur at all—most of the ongoing effort will be development-related. In most cases, after your app is in the App Store, your developer will probably be able to use the existing design assets in future versions of the app.
Due to how hot the market is for building apps, and especially iPhone and iPad apps, there will be no shortage of people willing to “help” you. You can avoid those types of inquiries by beginning your search the right way and then knowing how to better vet potential team members. Trust your instincts and judgment throughout this process. If you have a bad feeling about a person or a company, don’t proceed.
If possible, try to work with people you know or who are in your larger network. Making that happen may include asking friends or family to make introductions for you, or hitting LinkedIn and Twitter to ask your colleagues and peers to do the same. It’s better to work with people you have done business with in the past or who come with a referral from a contact. Getting a referral can help you avoid this search entirely.
With referrals or with people you find outside your immediate network, always ask for client references. Talk with these references about their apps and App Store experiences. If someone doesn’t have any client references because he is just starting out, don’t be completely scared away. If he can demonstrate a reasonable amount of competency, use his lack of references as a negotiating point to lower costs.
Portfolios are a great means to understand a designer’s or developer’s skills. A portfolio showcases the apps or the parts of the apps that someone previously built.
At first glance, a portfolio may seem relevant only to a designer, since it’s easy to visually inspect the work. The nice thing about the App Store, however, is that you can download any portfolio app (see Figure 4-1) and try it yourself. That allows you to experience a developer’s work too by seeing how responsive an app is and whether it seems stable or crashes.
The other use of the portfolio is that you can discuss the apps with the designer or developer. Ask why her app looks or functions the way it does, what some of the tough decisions were, and what she considers the best and worst parts of the app (especially what she believes needs to be improved). I find the best way to do that is to focus on two or three screens. Try to really dig into the details beyond what’s obvious. Another reason this step is important—and you might be surprised by this fact—is that some people will misrepresent apps as part of their portfolio when they really are not. That won’t be possible if you have these types of discussions.
If their apps are fairly different from what you want to build, ask them how they’ll approach designing or developing your app. Guide them to be more specific and ask what they see as the big challenges with your app compared to what they previously built. A good approach is to point them to one or two apps that are similar to yours and then follow the same exercise as with their portfolio apps by focusing on two or three screens and then discussing with them.
Aside from making sure your team members have the right skills and talent, you will want to make sure you find people who are willing to agree to some basic rules regarding confidentiality and protection of your idea and application. This includes maintaining your rights to your idea and the assets your team develops for your app.
This protection is often accomplished through a nondisclosure agreement (NDA) and a standard contractor agreement between you and any of your team members. The purpose of the NDA is to define the terms under which you and your contractors will disclose confidential information to each other during the course of the engagement. It may provide protection of that information for some period of time (as specified in the agreement) so that it cannot be shared with third parties.
The main goal of the contractor agreement is to establish your rights to the assets your contractors develop. It may also include a description of what tasks or milestones your contractors must accomplish to receive payment.
Note
These guidelines are for informational purposes only and should not be construed as legal advice. Although NDAs, contractor forms, and related resources are available for free on some websites, such as LegalZoom.com, Nolo.com, and Docstoc (http://www.docstoc.com/), they may not fit your specific situation. I strongly recommend that you consult an attorney to ensure that your agreements are accurately drafted and enforceable.
In Chapter 1, I mentioned that $10,000 was a fair number to use for the cost of a well-built app. Sure, it is possible to pay less than that (and much more!), but in general, as that price goes down, so will the quality of the app. To quote Davide Di Cillo, an iPhone app developer and the founder of GetAppsDone.com, who is interviewed at the end of this chapter:
...keep in mind that a $20 per hour developer isn’t always cheaper than a $100 per hour developer. I’ve worked with developers that even if more expensive, were saving me money by being faster and more responsive.
For some background on why that number is in some ways a conservative estimate, note that many apps will take between four and eight weeks to build, with the average being six weeks. With a full-time developer (40 hours per week) and a part-time designer (20 hours per week), the average man-hours per week is around 60. Six weeks multiplied by 60 hours per week equals 360 hours. Solid designers and developers will charge around $100 per hour, with top talent peaking at around $150 per hour and lower-end U.S.-based contractors charging around $65 per hour. Using the $100-per-hour rate yields a total of $36,000 (360 hours × $100 per hour). That number can quickly fluctuate: if your app took four weeks to build (240 hours) and the average was instead $75 per hour, the total would be $18,000 (240 hours × $75 per hour).
Note
For games, the number of total hours is much higher, and ranges between 700 and 2,000 hours. This equates to three to six months of work, depending on the number of developers working on the game simultaneously.
It may astound you to know that depending on complexity, the cost of developing an app can range from less than $5,000 to more than $100,000. That lower boundary typically involves working with offshore or independent developers, whereas the higher number is from hiring professional companies or agencies. Looking at the median cost from TheyMakeApps.com (see Figure 4-2), a resource for finding app developers, you can see that development cost lies within the $10,000 to $15,000 range. Contractors have also requested that TheyMakeApps.com add a $50,000+ category to assign to their listing.
Figure 4-2. A TheyMakeApps.com fee breakdown based on contractors self-reporting what they charge to build apps
One last note about these costs: on the lower end, they largely assume that you are acting as the product manager for your app, performing the roles described earlier. This implies that your “services” are free. To perform a more rigorous cost analysis, you might consider including your hours in these estimates. Assign yourself an hourly rate—perhaps what you could make if you were consulting, based on what you make at your job, or by actually paying yourself some sort of salary—and multiply that by the number of hours you plan to spend on your app per week. Add that to the previous numbers to get another perspective on costs.
Hopefully, you didn’t damage this book or your screen too badly after reading the preceding paragraphs. The reality of the situation is that you are in a hot market in which people with the skills to build apps are scarce resources. You’ll find that the best designers and developers won’t haggle with cost estimates or their rates because others will gladly pay them.
To reconcile these costs, start with the quantification of your app as performed in Chapter 1. You should understand the larger purpose of this effort (e.g., it’s the start of a long-term investment in the mobile space) and, if you are pursuing a paid app, have some sense of what the financial returns should be.
Although I’ll show you some practical ways to lower costs, you need to be able to reconcile them with the motivation behind your app. Mentally you must be “all in” with your app, equally committed to it and prepared to lose anything you’ve invested. That’s a telling yet truthful statement about the nature of the App Store.
Note
Remember that if you continue to update your app once it is launched, each update will also come with a cost. Depending on what the updates include, they typically will equate to a fraction of what it costs to build the entire app. Not accounting for them, however, can give you a false sense of out-of-pocket costs.
Ensuring that your product assets (e.g., initial research and wireframes) are as detailed as possible is a smart way to reduce your costs. If you have little or no experience building software, some of these items will not be more fully completed until your team is in place. Even before then, however, do your best to think through the biggest challenges of your app. Bringing more information to your potential resources will help them better estimate costs and build your app more efficiently. Both of these will impact the bottom line of what it costs to build your app.
Second, try to keep the first version of your app as simple as possible. That means scaling the app back to its key features, choosing what has proven to be most important to your customers. This approach not only is helpful from a cost perspective, but also is a strategic decision for your app. Many apps try to do many things at once, and as a result, they do nothing well. Thus, by focusing your first release in this way, you’ll reduce the risk of overinvestment while also developing a better app.
The experience, quality, and location of those you contract can drastically impact costs, but not necessarily the way you’d think. For example, working with offshore or less experienced resources (such as students or recent graduates) can put your app cost more in the range of several thousand dollars. Yet, this usually can be accomplished successfully only by people who know how to collaborate with these types of designers and developers to achieve the results they want. Those who are less seasoned or have no experience in this area often choose the cheaper option, only to spend thousands of dollars with an unsatisfactory outcome, or worse, with nothing to show for it. The investment, in this case, becomes considerably higher than initially agreeing to a more costly estimate or hourly rate from more experienced or proven resources.
There are additional challenges with offshore or overseas resources, including language barriers and adjusting for time zone differences. Again, it’s possible to overcome these problems, but few have gotten the formula just right; the benefits are numerous to those who have.
A lesser-known way to reduce the cost of building your app is to find developers who are willing to reuse code from their other apps or client projects. The reason is that the actual development usually represents the largest portion of the cost. You might even consider working with a developer who has developed an app that is similar to your idea.
The caution for this approach is that you’ll need to ensure that you have the full rights to these assets—through a written agreement—in case you sever your relationship with the developer or your app is acquired. In the first case, you wouldn’t want the developer to keep the code if he is no longer involved in the app. In the second case, you wouldn’t want the developer to claim that your app couldn’t be sold or that a portion of the proceeds were owed to him.
On this point, I want to conclude this section by addressing the use of partnerships and revenue sharing (referred to collectively as “partnerships”) as a way to lower costs. It’s possible that instead of paying for help, you might convince people to lend their skills or assets for free in exchange for partial ownership of your app, a share of the app’s proceeds, or recognition (if you have a free app).
In most cases, I find that one or more parties in partnerships become disillusioned by the perception that another party is not as committed or is not doing as much work as other members. This causes frustration, distrust, and often a dissolving of the partnership before the app even makes it to the App Store.
One remedy to this situation, which does not make a partnership foolproof, is to have a written agreement that stipulates how the equity is divided beforehand. This solution also has its problems, because it may not be clear what each effort is worth. For instance, since the main value you might bring to your team is your idea and your understanding of your app’s landscape, doing “less work” in terms of building your app shouldn’t necessarily imply that your share of the app should be lower than others’.
Another major issue with partnerships is that disappointment and frustration can occur if the app does not immediately meet expectations when launched into the App Store. Part of the underpinnings of a partnership is the promise of the app. If it appears to have no promise through its download count or sales numbers, your partners may be unwilling to continue to invest their time in it. This can leave you in an unsettling predicament.
If you are absolutely determined to build your app using a partnership, at least do so with people you’ve worked with in the past or have known for some time. And still be sure to put the terms of your partnership in a written, signed document. My overall recommendation is that if your idea is worth pursuing, consider some of the options to reduce your costs, but be willing to invest money in it. Doing so will simplify legal paperwork, and ultimately will allow you to drive and own the direction of your app.
Note
Visit http://kenyarmosh.com/appsavvy to help estimate the cost to build your app. You’ll also find information about how to create a reusable template to solicit contractors, as discussed in the next section.
Get App Savvy now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
